quote path in CxxFlags

[kevinushey]

Pull Request Template for Rcpp

Closes #1188.

Checklist

• Code compiles correctly
• R CMD check still passes all tests
• Preferably, new tests were added which fail without the change
• Document the changes by file in ChangeLog

[eddelbuettel]

It's a wee bit circular but I just approved the changes I made ... after requesting them first :) Will let it sit for a bit and merge if nobody complains...

[kevinushey]

Thanks! I approve of your changes as well, not that you needed it here. :-)

[stefanoborini]

Is it possible that this change has compromised building on macOS monterey and R 4.0.4? I am seeing a failure on 1.0.10 that was not occurring on 1.0.7:

clang++ -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG   -I/usr/local/include  `/Library/Frameworks/R.framework/Resources/bin/Rscript -e "Rcpp:::CxxFlags()"` -fPIC  -Wall -g -O2  -UNDEBUG -Wall -pedantic -g -O0 -c src/myfile.cc -o myfile.o
Using environment default (R version: 4.0.4, platform: x86_64-apple-darwin17.0)
src/myfile.cc:2:10: fatal error: 'Rcpp.h' file not found
#include <Rcpp.h>
         ^~~~~~~~

The content of src/Makevars is as follows:

## Use the R_HOME indirection to support installations of multiple R version
PKG_LIBS = `$(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"`
PKG_CXXFLAGS=`$(R_HOME)/bin/Rscript -e "Rcpp:::CxxFlags()"`

I am unsure if this is due to the addition of the quotes, but it seems so. In 1.0.7 I obtained:

$ clang++ -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG   -I/usr/local/include  `/Library/Frameworks/R.framework/Resources/bin/Rscript -e "Rcpp:::CxxFlags()"` -fPIC  -Wall -g -O2  -UNDEBUG -Wall -pedantic -g -O0 -c src/myfile.cc -o myfile.o
Using environment default (R version: 4.0.4, platform: x86_64-apple-darwin17.0)
In file included from src/myfile.cc:2:
In file included from <redacted>/.envs/default/lib/Rcpp/include/Rcpp.h:27:
In file included from <redacted>/.envs/default/lib/Rcpp/include/RcppCommon.h:167:
<redacted>/.envs/default/lib/Rcpp/include/Rcpp/internal/r_coerce.h:255:7: warning: 'sprintf' is deprecated: This function is provided for compatibility reasons only.  Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead. [-Wdeprecated-declarations]

<compilation continues and finishes>

[eddelbuettel]

Why do you use Rscript -e "Rcpp:::CxxFlags()" which was deprecated around a decade ago? If you do non-standard things, and it breaks, you get to keep the pieces. Maybe try a quick Rcpp.package.skeleton("newpackage") and compare the basic setup to what you use, you are likely better off using what everybody else is using as it is more tested.

Edit And PKG_LIBS = $(R_HOME)/bin/Rscript -e "Rcpp:::LdFlags()"` has been unused / not recommended for a decade. If you prefer the setup that was current then, maybe just a commensurate Rcpp version such as, say, Rcpp 0.10.0 from 2012. As you may be aware, CRAN tests quite rigorously, and there is a reasonably large user base. So if something breaks "just for you" maybe it was a commit from last November you now point at.

[stefanoborini]

Because the package was developed a decade ago.

[stefanoborini]

but that's beside the point... it used to work until 1.0.7. I am not saying I won't change the process. I am just puzzled that it broke for this.

[eddelbuettel]

You appear to want to have it both ways: Use your code from ten years ago unchanged, yet rely an brand-new contributed code? Is see a disconnect here. Many packages among the 2600+ on CRAN that use Rcpp also started a long time ago, yet managed to update their processes.

In any event, we (and CRAN) test rigourously, and I think most people find that playing with (rather than against) that setup works for them. If you manage to isolate a breakage, please try to reproduce it in a minimal setup on current versions.

[stefanoborini]

I don't deploy on CRAN. All I know is that I get dumped a 10 years old package on my lap and have to make it work, and all I know is that with 1.0.7 of Rcpp it worked and with a patchlevel version bump it doesn't.

[eddelbuettel]

So maybe just use an Rcpp version from ten years ago as I suggested earlier?

Rcpp versions 1.0.8 and 1.0.9 and 1.0.10 all got released after 1.0.7. You have plenty of choices to pin the "historic" Rcpp-using package you work with to other versions that most likely once worked with it. There is a subculture out there that thinks pinning is a solution; it is particularly popular with users of other languages that do not have a system like CRAN and fail to appreciate how to work with CRAN (and benefit from it). So be it -- it's a big tent out there and people can do as they please.

But Rcpp is a CRAN package, and one that works hard to be in good standing at CRAN. And which has a 15-year history of being in good standing. You are more than welcome to ignore that body of work and use random code combinations, but you cannot expect us to appreciate such undertakings. We prefer to focus on other things which also happen to be meaningful to other users.