On Mon, 2017-03-20 at 16:38 +0100, Jeroen Ooms wrote:
> On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer
> wrote:
> > I have just added some code to ensure that the compilation fails
> > with an informative error message if a specific C++ standard is
> > requested but the corresponding compiler has
On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer wrote:
> I have just added some code to ensure that the compilation fails with an
> informative error message if a specific C++ standard is requested but the
> corresponding compiler has not been defined. Please test this.
I can confirm that (at l
On Sun, Mar 19, 2017 at 9:09 PM, Martyn Plummer wrote:
> I have just added some code to ensure that the compilation fails with an
> informative error message if a specific C++ standard is requested but the
> corresponding compiler has not been defined. Please test this.
Are you sure we shouldn'
vel
Subject: Re: [Rd] Experimental CXX_STD problem in R 3.4
On 18 March 2017 at 14:21, Jeroen Ooms wrote:
| R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11
| / CXX14 / CXX17.
R 3.1.0 introduced CXX11 support. R 3.4.0 will have CXX14 support. So I
would only refer to
On 18 March 2017 at 14:21, Jeroen Ooms wrote:
| R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11
| / CXX14 / CXX17.
R 3.1.0 introduced CXX11 support. R 3.4.0 will have CXX14 support. So I
would only refer to the CXX17 part as experimental.
| However on most platforms, the
R 3.4 has 'experimental' support for setting CXX_STD to CXX98 / CXX11
/ CXX14 / CXX17.
However on most platforms, the R configuration seems to leave the
CXX1Y and CXX1Z fields blank in "${R_HOME}/etc/Makeconf" (rather than
falling back on default CXX). Therefore specifying e.g CXX_STD= CXX14
will
