Location of headers and binaries

[SylvainCorlay]

I am opening the issue here but it applies to all three conda packages rcpp, rcpp-eigen and rcpp-armadillo.

The issue with the way the conda packages are installed is that it makes use of the CRAN packages, which I think is bad practice. For example, the CRAN package for rcpp-armadillo vendors the armadillo headers in a subdirectory of inst, instead of depending of the Armadillo conda package.

Instead, the headers and binaries for rcpp, rcpp-eigen, and rcpp-armadillo, should fall in their natural locations under the conda installation prefix, and the headers for dependencies Eigen and Amadillo should not be vendored in the conda package.

[SylvainCorlay]

cc @eddelbuettel it seems that the Debian packages for rcpp & co have the same issue

Is there a means

• to disable the vendoring of third-party headers?
• in the installation of the package to install the relevant bits it the general installation prefix?

[eddelbuettel]

Unsubscribing here as I have nothing to do with Conda (apart from occassionally seeing its users struggling with our normal R packages) and not enough bandwidth to get involved pro bono.

If there are genuine upstream issues with R packages of mine feel free to bring them to their respective trackers.

[SylvainCorlay]

Well, the question was about rcpp and about the way you package it for Debian.

[SylvainCorlay]

cc @romainfrancois

[romainfrancois]

afraid I'm not too familiar with conda.

As for RcppArmadillo, it does indeed "vendor" armadillo headers in inst, but iirc there's also a few extra bits and pieces there as well.

The reason for vendoring was to make it easy to offer RcppArmadillo on various platforms that R supports, which all have their ways to express dependencies ..

[SylvainCorlay]

What I have done for xtensor-r is make it a regular C++ package. There is a cmake target called CRAN that produces the tarball for the CRAN package, which vendors the core xtensor headers, so that I can either:

• create a CRAN package vendoring everything (core xtensor and xtensor-r).

or

• install xtensor (the core package) and xtensor-r (the "additional bits and pieces") in the general include directories, which is what the recipe for the conda/debian package will probably do.

I wonder if I missed something before I make the first release.

[romainfrancois]

It might be interesting to write an article/blog post about this approach.
One thing I'd say you might be sacrificing is the ability to easily install it via devtools::install_github.

As long as your generated tar.gz passes R CMD check --as-cran you're fine, the way it is generated is not that relevant.

You may want to also try rhub::check_for_cran( "{...}.tar.gz" )

[SylvainCorlay]

As long as your generated tar.gz passes R CMD check --as-cran you're fine, the way it is generated is not that relevant.

Yes, it does, it is part of the CI (linux, mac and windows). Also, this allows me to not add the headers generated by Rcpp to the repository.

It is a good idea, for the blog post...

[romainfrancois]

I get your point, we sort of live with pushing the code Rcpp (and e.g. roxygen) generates.

This has pros and cons, but again, the ability for users to just simply devtools::install_github a 📦 is something we like