Should the R package also install the headers? about mlpack HOT 7 CLOSED

Yup and yup!! (I 'lazily' caught up yesterday and used my Launchpad PPA to build an Ubuntu binary of Debian's most recent package, mlpack 4.0.1 (and filed a Debian bug report to kindly roll forward to last month's 4.1.0) and verified that yes indeed we only need the headers).

Bulletpoint one: Our good friends RcppArmadillo, and then of course also RcppEnsmallen, are prime example. See how they use the directory inst/include/: RcppArmadillo which contains Conrad's code unchanged (I just the unused cmake config setter as no cmake is touched in an R packahe build) and RcppEnsmallen doess the exact same thing. In fact, so do hundreds of R package. The key that every directory or file below inst/ ends up being installed 'as-is' in an R package installation. So is the perfect vessel for header librariess -- and I have done just that for 10+ years for Armadillo, a subset of Boost (package BH), Eigen, Asio, ... and more.

R uses this by declaring LinkingTo: in the DESCRIPTION file. That tells R to construct a -I.... flag to whereever the package that is referenced on that machine points. And ... that is all. Eg when I install an old user of RcppArmadillo I see (to grab just one line)

 ccache g++-12 -I"/usr/share/R/include" -DNDEBUG  \
           -I'/usr/local/lib/R/site-library/Rcpp/include' \
           -I'/usr/local/lib/R/site-library/RcppArmadillo/include'   \
           -fpic  -g -O3 -Wall -pipe -pedantic   -c expmMat.cpp -o expmMat.o

because the package in question has

  LinkingTo: Rcpp, RcppArmadillo

So users of (R package) mlpack would just need to add LinkingTo: mlpack (well: and RcppArmadillo, RcppEnsmallen) and be done.

In an ad-hoc R session you that taken care of by Rcpp::sourceCpp() because we declare // [[Rcpp::depends(RcppArmadillo)]] which does the same thing in non-package builds: Add the needed -I....

This just works and is fabulous. Case in point is my updated SO answer showing use of RcppArmadillo, RcppEnsmallen, mlpack (header-less, relies on my system headers, this would fix it) and a switch to C++14.

Bulletpoint two: My cmake-foo is weak but just how we in recent PRs for the R package added an explicit copy of a single file here or there we would have to ensure that the headers end up in inst/include as

  inst/include/mlpack.hpp
  inst/include/mlpack/**             # recursively

and then we should be done. That is probably handled either or two install statements and I would hope we do not have to enumerate all the include header files explicitly.

from mlpack.

I see -- it didn't fail for me here but maybe I 'got lucky' as I have libcereal-dev 1.3.2 installed. I could try in a container to use a more restricted cleaner setup.

If cereal is needed, it should go to inst/include too and we would effectively 'vendor' it. (And one of the two of use should maybe talk to Wush to update Rcereal but that is for another day).

from mlpack.

And on CRAN -- love to see it. https://mastodon.social/@[email protected]/110605692538355162 ie

and

from mlpack.

@eddelbuettel I definitely agree with the idea and I'm happy to implement, but a couple of clarifying questions:

• What are the default include directories for Rcpp? If we install mlpack headers into the R environment, and the user also has mlpack headers installed via their system package manager, will Rcpp::sourceCpp() use the headers in the R environment?

• I see that the headers are distributed with the tarball itself, so from the CMake side, the build process appears to be correct. But I suspect there is some part of the R package build process where we need to add an installation line for the headers or something like this. Can you point me towards where this change needs to be added? I can't seem to easily locate where the actual build instructions inside the package are.

Thanks!

from mlpack.

I see! Thanks for the comprehensive answer. If everything in inst/ is installed automatically, then I would just need to move the mlpack headers from src/ to inst/, and maybe make some small updates so that the package still builds correctly (easy enough).

However, one little gotcha: we don't use the RcppCereal package because it throws warnings on CRAN. Here's the relevant comment in the CMakeLists.txt:

  # In case of R_Bindings we are copying all of these header to
  # <package>/src/cereal/ because the currently-packaged version
  # of Rcereal throws warnings on CRAN.

So, should I also put the cereal headers into inst/? Or could we run into issues where a user has installed Rcereal, and then mlpack attempts to install new headers over it? Without the cereal headers, compilation will fail.

from mlpack.

Awesome. Thanks again for the help and explanation. I still want to see it build on Azure Pipelines, but I'm pretty sure #3488 handles this. 👍

from mlpack.

resolved in #3488

from mlpack.