Conditional attributes don't work (e.g. [[Rcpp::depends]] inside #ifdef)

[tom93]

Hi, when I put // [[Rcpp::depends(...)]] inside an #ifdef, Rcpp "sees" this attribute and attempts to load the package even when the condition is false. Is there a way to make the Rcpp::depends attribute conditional?

I tried putting the attribute in a separate .h file and conditionally #include-ing that file, but that has exactly the same issue -- Rcpp "sees" the #include and always follows it regardless of the enclosing #ifdef.

My use case is that I have a .cpp file (for use with sourceCpp) with an optional dependency on some package "foo". I'd like to let users enable the use of foo by setting PKG_CPPFLAGS=-DFOO. I can wrap the C++ code that uses foo in an #ifdef FOO, but that doesn't work for the Rcpp::depends attribute (which is always "seen" by Rcpp and causes an error if foo is not installed).

The best workaround I can think of is to read the .cpp file, conditionally delete the #ifdef FOO ... #endif, and pass the result to sourceCpp(code=...). I'd appreciate any better ideas.

I think the proper solution is for Rcpp to run the real C preprocessor instead of trying to emulate it, but I'm not sure how difficult that would be. At the very least it would be nice if the current behaviour was documented, because the inconsistency with the real C preprocessor is surprising (#include is respected, but #ifdef etc. are not).

[eddelbuettel]

"That's just how it works" as the compileAttribute() scanner is R-based and does not know about the preprocessor. You analysed this correctly, and I intend to close this in a few days as 'not planned'.

As an example, I sometimes have code with a "big" outer #if defined(SOMETHING) and routines for R in both the true and false branches. It took me a few years too to realize I could only have the corresponding [[Rcpp::exports]] in one of the two as both halves are seen by R and you can only define one signature once.

For your Rcpp::depends you will have to think of a different solution, likely at the package level using configure (which can be a shell or R script too). There simply are tasks for which Rcpp::sourceCpp() and friends are not powerful enough. As alternatives exist, this is not that critical an issue. Lastly, improvements are always possible so if you want to try to rewrite the inner logic here we would be happy to review potential contributions.

[tom93]

Fair enough. I might try to write a PR to document this. Thanks for the suggestions.

[eddelbuettel]

I will admit I too thought about invoking the preprocessor first, maybe as an option? "It may just work." I never tried as there are always other fish to fry...

[tom93]

I thought some more about invoking the preprocessor and discovered a problem with the header search path that seems like a roadblock; I'll document it here in case anyone considers using that approach in future.

The final search path depends on the Rcpp::depends attributes. When running the preprocessor for the first time, the final search path is not known, so headers from the dependency packages will not be found. There doesn't seem to be a way to make GCC ignore missing headers (-MG/--print-missing-file-dependencies is close but requires -M/--dependencies mode which is not useful). My best idea is to require the Rcpp::depends attributes to occur before any related #include statements, and run the preprocessor multiple times -- each time update the header search path based on the attributes found so far, so that the preprocessor can get further next time. That's ugly and slow.

[eddelbuettel]

Thanks for spelling it out. I also mostly pondered that there must be an 'obvious reason' blocking this as otherwise @jjallaire would have gone this route at the start.

[jjallaire]

I didn't investigate running the pre processor (I think it might be non-trivial to compute exactly the right flags for it). That said, I recall we did something like this for the clang integration in RStudio (cc @kevinushey)

[kevinushey]

One potential option worth exploring would be to run the moral equivalent of gcc -E <file>, and then run our attributes parser on the resulting file.

Getting the compiler flags right might be challenging but we could probably pull out pieces by invoking R CMD SHLIB --dry-run on the associated source file first. The devil is in the details, though.

[eddelbuettel]

I am quite happy with the status quo which has served us well. Casual use can do sourceCpp() and cppFunction(), extended use in a package has the configure (or cmake if one must) avenue open. No need to add extra fragility.