R-devel does not set CXX1X, CXX1XSTD on compilers without full C++11 support. This is a departure from the current behavior of R 3.3.2, which does set these variables if the compiler has at least some support for C++11.
A reproducible example of the behavior can be found at https://github.com/jimhester/rocker/tree/master/r-devel/precise#readme along with instructions on reproducing. The repository directory can be checked out using git, or svn with
`svn co https://github.com/jimhester/rocker/trunk/r-devel/precise`.
A example case is ubuntu precise, which uses g++ 4.6.3. This compiler version does not have full support for C++11, but does have partial support. In previous R versions CXX1X and CXX1XSTD were set to `g++` and `-std=c++0x` respectively. With the current R-devel they are unset.
If a R package uses only supported C++11 features they can be successfully compiled with g++ 4.6.3 using R 3.3.2, but will fail to compile with R-devel.
Ideally we would like to retain the flags for partial support, while still setting e.g. `-std=c++11` if the compiler has full support for C++11.
I don't think I can do anything about this. The macros that we use to determine whether a compiler supports C++11 are adapted from standard macros in the GNU autoconf archive. We use ax_cxx_compile_stdcxx_11.m4 (serial 3) in R 3.3.x and ax_cxx_compile_stdcxx.m4 (serial 4) in R-devel.
There is a ratchet effect as the macros evolve and become more stringent. For example the number of lines of C code in the test program for C++11 is 18 in the current release of R and 282 in R-devel. So it is not surprising that an older compiler, supporting only a few C++11 features, is no longer accepted.
I'm sorry for people on older platforms who find that things will stop working. In my defence, end of life for Ubuntu precise is in April, when the release of R 3.4.0 is expected.
That is fair and I expected the cause was similar to what you described. Is there any change we could make that would produce more useful error messages than the current behavior? Right now the CXX1X variables are simply unset, which makes for very confusing error messages. See <https://travis-ci.org/hadley/devtools/jobs/153316405#L1973 for an example>.
Ideally if a package has `CXX_STD = CXX11` or `SystemRequirements: C++11` and the relevant CXX1X make variables are unset R should fail with an appropriate error indicating the compiler does not support C++11.
Thanks for looking into this!
OK I have added some informative error messages to R-devel. You should now get "C++11 standard requested but CXX1X is not defined" in your example, and similar messages for the other standards.
Great thanks Martyn!
Sorry I missed this topic.
The problem with strictly enforcing CXX_STD is that you encourage package authors to avoid it, which is unfortunate. A package author might prefer CXX14, but can't actually specify this if this means R refuses to build the package on most systems, even though it would actually work.
Ideally, R would raise a warning instead of an error when building a package with an unsupported CXX standard, and then fall back on the latest supported standard. For example when the compiler is unaware of "-std=c++14", instead of leaving Makeconf fields blank, configure could set:
CXX14 = CXX11
CXX14FLAGS = CXX11FLAGS
SHLIB_CXX14LD = SHLIB_CXX11LD
SHLIB_CXX14LDFLAGS = SHLIB_CXX11LDFLAGS
etc. This allows package authors to adopt modern standards without losing users with a slightly older compiler. Anyway apparently not many people care about LTS systems so I will stop complaining about this.
I have made the C++11 feature tests conditional, so that if gcc < 4.8 is used then the same feature tests are used in R-devel as in R 3.3.x. If this does not cause any trouble then I will port it to R-3-4-branch in due course.
This change means that the C++11 support will be maintained for LTS platforms using older releases of gcc. I have tested it on CentOS 6 (gcc 4.4.7).
Jeroen, I don't understand the point your are trying to make in your last comment. I'm closing this bug report now but if you want to take these issues up on the R-devel list then we can continue the conversation there.