Planning to potentially (re)move some legacy internal header files (original) (raw)

RcppArmadillo always had a bit of an ad-hoc laying in its (user facing) header files. This was not of great importance as the only file users would typically include was RcppArmadillo.h so what was in the (top level of) inst/include was not that important.

Somewhat recently, Rcpp generalized away from (essentially only) Rcpp.h by allowing a set of headers to be included:

// in the following you would pick one of these #include <Rcpp/Rcpp> // as before: everyhing #include <Rcpp/Light> // no Modules, which many packages can skip #include <Rcpp/Lighter> // no RTTI (and that implies no Modules too) #include <Rcpp/Lightest> // no Sugar (which most will want to keep)

We now support this in RcppArmadillo to with matching choices RppArmadillo, Light, Lighter, and Lightest.

At the same time, it may also make sense to move some internal header files around. We now have

edd@rob:/git/rcpparmadillo/inst/include(master)$ ls -1 armadillo armadillo_bits RcppArmadillo RcppArmadilloAs.h # replaced by RcppArmadillo/interface/RcppArmadilloAs.h RcppArmadilloConfig.h # replaced by RcppArmadillo/config/RcppArmadilloConfig.h RcppArmadilloExtensions RcppArmadilloForward.h # replaced by RcppArmadillo/interface/RcppArmadilloForward.h RcppArmadillo.h RcppArmadilloSugar.h # replaced by RcppArmadillo/interface/RcppArmadilloSugar.h RcppArmadilloWrap.h # replaced by RcppArmadillo/interface/RcppArmadilloWrap.h README edd@rob:/git/rcpparmadillo/inst/include(master)$

where the five highlighted files are internal in nature and should not be called directly by end-user packages. The actual files have been moved as indicated, and the 'legacy' locations just act as redirectors including them. A few weeks ago we ran a full reverse depends check and identified four packages that need adjustments we plan to make in PR in the next few weeks.

It is our hope that with a bit of coordination we should be able to remove these legacy files. Time will tell, and we may find that what we have now is the best we can do as there may always be 'unidentified packages' using them.

The packages needing change as of 30 Nov 2022 are