I develope a package using Rcpp, cpp include "windows.h" library, but this package is not available on Linux, so I decided to achieve the same function using reticulate package to call python package, how should I make package detect installed on which platform ?
If on Windows platform, installing my package will compile cpp file , if on Linux , installing my package will not compile cpp file but using my r code inside.
For example:
Windows:
myfunction<-function(){
.Call(C++ function)
}
And also avoid compile cpp file in src folder or there will be error : "no windows.h library"
Linux:
myfunction<-function(){
library(reticulate)
import(py_package)
}
Maybe you can rethink your approach and provide a C++ solution on platforms other than Windows too? But in short you can the following:
In R
Use eg if (Sys.info()[["sysname"]] == "Windows") to test for windows, and in the else branch call the replacement
In C/C++
Use #define tests such as #if defined(_WIN32) to bracket the #include <windows>, and also the body of your function. Just return eg nothing on other platforms.
Many packages do things depending on the platform they are on. Feel free to look around at existing sources -- CRAN has over 12k and GitHub is treasure trove too.
Related
I have some C++ code that I intend to export into my r package using Rcpp. However, this code links to fftw3 via
#include <fftw3.h>
at the top of the file. When I try to compile this code, I unsurprisingly get the error
fatal error: 'fftw3.h' file not found
What is the proper way to link to this file so that it will be available upon compilation of my package? I know that a Makevars file can generally be used to link to system libraries but since this library is external I'm not sure what to do.
Thanks,
Eric.
Please see the Rcpp vignette Rcpp libraries -- which is also this arXiv paper.
There are many examples among the 2400+ CRAN packages using Rcpp. My hunch would probably be to look at what I contributed to the nloptr package -- even though that is a more complicated scheme where we allow use either a system library if present (could be the case with fftw3 too) or downloand and build.
Rcpp has been used a lot to build such glue. The most common, and simplest , approach is to look for pkg-config and query it for headers and libraries. Please give that a shot (with some looking around CRAN or GitHub for examples).
Edit: There is also an (old) fftw3 package by Gabor at his previous employer's GitHub org as well as another CRAN package fftwtools (which, if memory served, I helped once too but I don't recall now what for).
In my R package I have C code that uses Intel MKL (and an open source library for C unit testing). I use CMake to build the C code. I also have Rcpp interface code that I use to call the C code from R.
I wanted to know if CRAN would accept this package given that you'd have to have Intel MKL and CMake already installed on your system for it to work?
I'm not too worried about the unit testing, I can always get rid of that, but I definitely need Intel MKL because I'm using linear algebra routines that are specific to MKL e.g. Sparse-Matrix-Dense-Matrix multiply etc.
The reason I need CMake is because currently, that's what I'm using to build a static library from the C code and manipulate the Makevars file in the package's src folder, so that I can link the Rcpp interface code against the C library.
My Makevars looks as follows:
PKG_CPPFLAGS=-I/usr/local/lib/R/site-library/Rcpp/include -I/opt/intel/compilers_and_libraries_2019.4.243/linux/mkl/include -I./C
PKG_LIBS=-L./C/cmake-build-release -lbcd -llog -Wl,--start-group /opt/intel/compilers_and_libraries_2019.4.243/linux/mkl/lib/intel64/libmkl_intel_ilp64.a /opt/intel/compilers_and_libraries_2019.4.243/linux/mkl/lib/intel64/libmkl_sequential.a /opt/intel/compilers_and_libraries_2019.4.243/linux/mkl/lib/intel64/libmkl_core.a -Wl,--end-group -lpthread -lm -ldl
This works on Ubuntu, but I'm worried about OS X and especially Windows. For example, here someone claims that Intel MKL is not compatible with minGW.
I know that there are many CRAN packages that use either MKL or CMake. But for the ones that I've investiaged, MKL is used as an optional BLAS library and CMake is used to build what's under the inst folder, which did not depend on external libraries. I've looked at writing R extensions and also the CRAN submission page but wasn't able to find find an answer. I thought that since there are more and more people interested in using CMake and MKL with R it would be good to have a SO post.
It seems you are tieing this up from the wrong end.
You have a more narrow and specialised solution you created (MKL, CMake).
Now you are worried that it may be too specialised. You are on the right path. First off, CMake is used by other packages so you could just declare it as a SystemRequirements:. Second, MKL is tougher but ... also truly specialised.
Methinks the general recommendation for a broader CRAN upload would be to
relax your code requirements: use MKL if present, but offer a fallback when not; now you no longer require MKL
ditto for CMake: keep it and depend on it, better still try to not require it as most 15000 other CRAN package no not need it either.
Once you hit these two you're ready for a CRAN upload. If all this seems to onerous, just stick with a GitHub repository or maybe a drat repo.
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!
After installing BH package, including following in .cpp file:
#include <Rcpp.h>
#include <boost/asio/ip/address_v4.hpp>
sourcing the cpp file with sourceCpp(".cpp file") is giving :
fatal error: boost/asio/ip/address_v4.hpp: No such file or directory compilation terminated.
In BH/boost directory there is no asio directory.
We never said Boost Asio was part of BH. Quoting from the DESCRIPTION with my highlighting in italics below:
Description: Boost provides free peer-reviewed portable C++ source
libraries. A large part of Boost is provided as C++ template code
which is resolved entirely at compile-time without linking. This
package aims to provide the most useful subset of Boost libraries
for template use among CRAN package. By placing these libraries in
this package, we offer a more efficient distribution system for CRAN
as replication of this code in the sources of other packages is
avoided.
Asio, thread, ... and a few others require linking and can never be part of BH.
I developed an application whose main graphical outputs relie on R through the very useful RInside. I would like to "deploy" my application under linux systems without having to systematically install R and the needed packages. For that purpose I simply copied all the R directory /usr/lib/R, all the needed .so library and set R_HOME variables to the correct path.
However, I get when executing:
Error in loadNamespace(name) : there is no package called ‘Rcpp’
Execution halted
While RInside is in the directory $R_HOME/site-library/RInside. I guess that I have more to do (and that my approach was quite naive). Does anyone already tries such a task and can help on what to do ?
Yes you need to install the other dependencies as well -- and Rcpp is needed to convert data seamlessly between R and C++.