I am writing an R package that needs to include an executable file (“mod.exe” in Windows environments or “mod” in Unix environments). One of the R functions in the package makes a call to the system that calls the executable as follows:
system(paste("mod", …))
Since CRAN will not accept packages with binary codeand because I would like the package to be portable to both Window and Unix systems, I would like to be able to just include the C source (“.h” and “.c”) files that can be used to build the executable “mod” in the source package. Ideally, when a user installs the R package, the source files should be compiled (with a C compiler available through Rtools on Windows or through a native C compiler on Unix) to create the executable “mod” during installation. Then, ideally, the executable “mod” would be stored in the binary package so that the aforementioned R function can call “mod” directly. (The .h and .c files have already been written so I do not want to rewrite or modify them.)
I've read http://r-pkgs.had.co.nz/package.html, looked through https://cran.r-project.org/doc/manuals/r-release/R-exts.html, and tried to find packages on CRAN that have already done something like what I’ve proposed, but haven’t been successful. I I attempted to solve my problem by putting all the C source files for “mod” into a /src directory in the source package along with a working makefile in the hope that this would cause the building of “mod” when the package was built and cause it to be stored somewhere in the binary package so that the R function could call “mod”. However, this did not work and when I try to look into the binary package the only thing I can see that was created is a /libs folder containing /i386 and /x64 folders, which both contain a dynamic linked library (on Windows, “RMCSim.dll”)-- I do not know what to do with this DLL.
If I create a version of the package in which the executable “mod” is placed into a package directory called “exec”, the R function can call the “mod” function. Unfortunately, this solution (1) is not portable to both Windows and Unix environments and (2) leads to a package that cannot be accepted by CRAN.
Please respond if you have any ideas for how to approach this problem or if you know of any examples of packages that do something similar with C source code. Thanks!
Related
never used R before. I need to integrate R into continuous build.
The script I got has the line
RUN Rscript -e "devtools::install_github('my-repo', auth_token = '"$Github_Token"')"
I know this command will download the entire repo, but how is the package installed? Is it looking for the .R files, or is it looking for the .rba files?
My goal is to integrate a build process with a CI. I found a way to construct these rba files through a docker container, but these will not be checked into github. I need to make sure the install doesn't require these rba files, then I can move these files somewhere else.
The function install_github installs a package the same as any other method of package installation, but automates the download from github for you. The remote repository needs to be an R package, meaning it needs to have at least an R/ directory containing R code, a DESCRIPTION file containing the package metadata, and a NAMESPACE file describing the package imports and exports.
For install_github to work, it should not inherently require that your rba files are present.
For more information on packages, I suggest reading R packages.
I am trying to build an R package (DESeq2) from source so that I can debug it. I've installed all the dependencies required and I'm following Hillary Parker's instructions for creating R packages. I'm running this on CentOS 6.6 using R-3.4.2.
I run :
library("devtools")
install("DESeq2", keep_source=TRUE)
It installs it in the directory with all my other R libraries. When I look at the installed DESeq2 library it is missing all the DESeq2/R/*.R and DESeq2/src/*.cpp files.
QUESTION : Where are these files and why didn't they get installed? This does not seem like the expected behavior.
R uses binary database format for installed packages to pack the objects into a database-alike file format for efficiency reasons (lazy loading). These database files (*.rdb and *.rdx) are stored in the R sub folder of the package installation path (see ?lazyLoad).
Even if
you are looking at the right place to find the installed package (use .libPaths() in R to find the installation folder)
and you have installed the package with the source code (like you did or
via install.packages("a_CRAN_package", INSTALL_opts = "--with-keep.source"))
you will not find R files in R folder there.
You can verify that the source code is available by picking one function name from the package and print it on the console. If you can see the source code (with comments) the package sources (R files) are available:
print(DeSeq2::any_function)
To make the source code available for debugging and stack traces you can set the option keep.source.pkgs = TRUE (see ?options) in your .Rprofile file or via an environment variable:
keep.source.pkgs:
As for keep.source, used only when packages are
installed. Defaults to FALSE unless the environment variable
R_KEEP_PKG_SOURCE is set to yes.
Note: The source code is available then only for newly installed and updated packages (not for already installed packages!).
For more details see: https://yetanothermathprogrammingconsultant.blogspot.de/2016/02/r-lazy-load-db-files.html
A colleague ported more than a thousand S functions and Fortran subroutines to R. The native R functions are contained in 5 .RData files and the Fortran subroutines are contained in 2 .dll files.
I can load these files into the R workspace using
for (i in 1:5){ load(list.files()[grep("RData",strsplit(list.files(),"\\W+"))][i]) }
for (i in 1:2){dyn.load(list.files()[grep("dll" ,strsplit(list.files(),"\\W+"))][i]) }
After some troubleshooting I know that the relationships between R code and the Fortran subroutines were already well established by the original author.
Now I want to create a package from these files because I'm unable to deploy my ioslides_presentations with these dll files since shinyapps.io is built with Linux. This is my first attempt at creating an R package, I don't intend to publish it to the CRAN, I'm only interested in generating a local zip file that I and my students can load.
MY PROCESS
After loading the functions in the workspace using the above code, I ran package.skeleton and system("R CMD build package") which successfully created "package_1.0.tar.gz". After completing the DESCRIPTION file, I put the .dll files I the src sub-directory and included useDynLib(DLL1), useDynLib(DLL2) in the NAMESPACE file.
However, when I run system("R CMD INSTALL build package_1.0.tar.gz") I get the following error:
Error in library.dynam(lib, package, package.lib) :
DLL 'package.dll' not found: maybe not installed for this architecture?
Error: loading failed
Execution halted
I've spent a great deal of time reading through "Writing R Extensions", "Advanced R" by Hadley Wickham, and the devtools documentation. Even so, I'm having difficulty deciphering useDynLib, .onLoad, Export, Call, and Makevars and which should be used for pre-compiled Fortran code.
I really don't want to parse through all of these functions to find which require export rules if I don't have to. I'd appreciate any help getting these .dll files loaded so I can finish creating this package
Thanks in advance,
Jason
When developing a package one can run R CMD check, which helpfully tells you any problems in your code (syntax errors, unstated dependencies, undefined variables).
Does a utility exist that will provide this functionality of R CMD check for individual source files?
I could create an empty package and move source files in their to check them, but that's both a pain, and overkill.
It sounds like you want to look at the codetools package.
From the Writing R Extensions Manual, I read that
As from R 2.14.0 the preferred location for the Sweave sources is the
subdirectory vignettes of the source packages, but for compatibility
with earlier versions of R, vignette sources will be looked for in
inst/doc if vignettes does not exist.
However, when I create a vignettes subdirectory of the package source, when I run devtools::check() or R CMD check I get a warning for Package vignette(s) without corresponding PDF. If I put the vignette (.Rnw and .pdf) in inst/doc the check completes without complaints. I tried looking in my library at installed packaged and did not see any directories named vignettes. Should I still use the deprecated location?
You put the .Rnw sources in vignettes/ as you did, but you missed out a critical step; don't check the source tree. The expected workflow is to build the source tarball and then check that tarball. Building the tarball will create the vignette PDF.
R CMD build ../foo/pkg
R CMD check ./pkg-0.4.tar.gz
for example will build a source package tarball from the sources in ../foo/pkg creating the .tar.gz package in the current directory with the package name and version appended. Then you run R CMD check on that source package.
If you want your vignette built for you put it in vignettes/ and build the source package. At some future date, R Core may remove the ability to build vignettes from inst/doc so go with the advised location now and avoid check the sources directly.
I had a hard time interpreting this too.
I believe the intention is that you should put the .Rnw file in vignettes/ and the PDF (suitably compacted) in inst/doc/, which technically agrees with the documentation if you read carefully enough. (That is, it says the sources should go in vignettes/. I don't see where it says in so many words that you ought to put the corresponding PDF in inst/doc/, but it doesn't not say it, and that interpretation seems to make R CMD check happy ...)
The resolution is in #GavinSimpson's answer (i.e. one is expected to build the tarball and then check it, rather than checking the source directory itself). (My two cents is that it might be best if R-core officially deprecated (and eventually removed) direct source checking rather than confusing all of us groundlings ...)