Should `Rcpp::compileAttributes()` include <Rcpp/Rcpp>?

[ms609]

I've been updating my packages to replace <Rcpp.h> with <Rcpp/Lightest>, as I understand to be the intent behind #1191. I notice that RcppExports.cpp, when generated with Rcpp::compileAttributes(), still includes <Rcpp.h>. Ought/can this be updated to use the new <Rcpp/...> syntax?

(Apologies for any misunderstandings; I'm still rather new to C++...)

[eddelbuettel]

❤️ You are approximately the second person on the planet besides me to think that #include <Rcpp/Lightest> might have merit.

And it coccured to me a couple of weeks ago that we have indeed not yet cared about RcppExports.cpp in this context. I guess we would need to, maybe with an option. To be seen...

But for now you only get lighter compilation for some files in your package. Sorry!

[eddelbuettel]

Actually, maybe you can use the old trick of including header file named the same as the package, and/or one as package_types.h. Those will be placed above RcppExports.cpp see e.g. this example from the tiledb package (see here

#include "../inst/include/tiledb.h"
#include "../inst/include/tiledb_types.h"
#include <Rcpp.h>

That, coupled with a #define of the header guard Rcpp_hpp should keep you from including the full file and allow you to tweak. But as I mentioned in other contexts, "nothing is faster than not compileing" so you may also want to look into ccache use, see e.g. this old post of mine

[eddelbuettel]

I was just noodling with a (not yet public, small) package and did it just there. I added inst/include/${PACKAGE}.h where the variable fills in what you think it does :) containing this (fixed!!) snippet:

// 'Empty' file to just include the lightest Rcpp variant
// ... and to set the guard to not re-include Rcpp
//
// This is then included by the generated RcppExports.h

#include <Rcpp/Lightest>
#define Rcpp_hpp

I am now thinking we could possibly 'automate' this and actually turn on #define Rcpp_hpp (in time for the next release in a few months).

Thoughts? Am I overlooking something? Can you try it too? I may do this in a few more place (unless I forget / get distracted).

[Enchufa2]

Unless I'm missing something, only the order matters. If Lightest is included first, then the proper defines are already in place and we don't need the additional define.

[eddelbuettel]

Doh. That is indeed how I set it up--layered, all ending up calling Rcpp.h because, well, we need it.

Silly me. Thanks for explaining my code to me. 🤦‍♂️

[Enchufa2]

I wouldn't like having to place a header under inst/include just to force RcppExports to take the right version. This has other implications and most packages don't need this. For a manual configuration, it would be nicer some src/RcppConfig.h that is loaded first if found. And if we can automate this, we can certainly make RcppExports take the right header directly, without intermediate files.

[eddelbuettel]

Many possible ways. You could add a -Dsomething to src/Makevars or add an entry Rcpp: to DESCRIPTION or whatnot.

The header-file in inst/include works today, and I needed it anyway as I needed to make sure RcppExports.h sees a third-party header for templated XPtr. Six of one, half a dozen of another. But we can iterate...