CRAN NOTE for package using Stan (suggest C++17)

seem to get the same issue with ctsem, though weirdly not when using github actions…

It only appears when you run R CMD CHECK under r-devel, you can see it on previous run of your actions here: fix savecomplexcalcs bug -- don't save for subject zero · cdriveraus/ctsem@c72c661 · GitHub

Sorry, I meant the error compiling due to overloaded size – I updated makevars to c++17 then tried to build.
“error: call of overloaded ‘size(const std::vector<std::vector >&)’ is ambiguous”

Is there a list of known issues here? If it was just ‘size’ then it’s easy enough to code around it, but I’m expecting an endless chain of such issues if I start working on that…

The issue is that the Math library has its own overloads for size() and apply(), and we weren’t appropriately qualifying them when they were called (i.e., math::size()). This isn’t an issue until we want to start compiling with c++17, since new overloads were introduced.

These functions are used fairly ubiquitously throughout the Math library, so it’s not the sort thing you’d be able to avoid by changing your Stan model

1 Like

@andrjohns I greatly appreciate you trying, this is the link to the package’s github.

Yes, thanks to @andrjohns !

FWIW, the only change I made to blavaan was in Makevars and Makevars.win (change CXX_STD from CXX14 to CXX17), and it now seems to be passing the r-devel compiler checks, see here. I think this means that I could submit it to CRAN, but I currently have a CXX14 version of the package in CRAN purgatory (submitted last week before I realized this was a thing), and I don’t want to annoy the CRAN gods.

Ok. ctsem compiles with c++17 when using the CRAN version of rstan / stanheaders. It runs into errors (e.g. overloaded size) when using rstan 2.26 from the stan repository. 2.26 is however necessary for people on windows who want to compile models themselves (because they are more complex). Would love ideas for how to work around this…

I’ve already opened a PR to backport the patches to 2.26, so rstan from the repos should be compatible soon

3 Likes

I tried just changing the system requirements as suggested here:

Got this note instead:

Specified C++14: please drop specification unless essential

So it looks like also need to change the Makevars

PR to update the Makevars has been opened here, so we’ll discuss and hope to have a fix out soon

3 Likes

Related to this C++17 issue: I uploaded a new package version to CRAN a few days ago and today received the message below. I am reporting back in case it influences the PR. (I edited the message to only include relevant parts; I believe @phcooney also received it)

These are now being compiled with C++17. Unfortunately they make use of
Boost headers that are not compliant with that standard, using functions
which were deprecated in C++11 and removed in C++17.

One workaround is to declared a dependence on C++14

Reading the headers suggested

PKG_CPPFLAGS = -D_HAS_AUTO_PTR_ETC=0

in src/Makevars[.win] would suffice, and I tested that for DDD (already
reported). Or you could add

#if __cplusplus >= 201703L
# define _HAS_AUTO_PTR_ETC 0
#endif

at the top of the files using Boost headers. (It looks like the stan
users should get that done upstream.)

1 Like

Thanks for the update! I’ll add that flag to the rstantools Makevars in the above PR (after running some revdep checks just in case)

2 Likes

Very thankful for the immense effort @andrjohns and others have put into updating rstantools and rstan. I’ve gotten a bit lost in some of the details though and would greatly appreciate a summary of the current state of things and what developers submitting R packages relying on rstan to CRAN should do.

In particular, my lingering questions are:

  1. Are the compilation problems with C++17 only for those running rstan 2.26 (i.e., CRAN’s rstan version 2.21 shouldn’t run into problems with compilation)? At first I thought this was the case based on @Charles_Driver’s post, but @edm’s recent post made me question this.
  2. For developers working on a Windows machine and thus using rstan 2.26, should we: 1) update our rstantools and rstan versions to incorporate @andrjohns’ pull requests and 2) Submit to CRAN, allowing rstantools to rebuild the src folder? I stumbled across this discussion on one of @andrjohns’ pull requests which made me wonder if before submission (step 2) we have to wait for the newest version of rstantools to be on CRAN.
  3. Is specifying C++14 as a SystemRequirements in one’s R package DESCRIPTION a feasible alternative solution if we continue to run into submission difficulties?
2 Likes

I am not sure that I can adequately answer all your questions, but it seems to me that there are two issues in this thread: (i) will CRAN accept a package that does not use C++17, and (ii) whether reliance on C++17 causes problems with various versions of rstan. My experience mostly involves the CRAN piece.

  1. I became aware of the C++17 issue because I tried to submit a new version of my package to CRAN (relying on rstan 2.21), I got a note about relying on C++14, and I had to change it before CRAN would accept it. But I notice that the note has changed in the past week or two: it now says “please drop C++14 unless it is essential”, whereas before (when I submitted the package), it said “please upgrade to C++17” (see the very first post in this thread). And you can see the new note in the rstanarm checks here.

  2. I thought that, if you are submitting to CRAN, you would have to use rstan 2.21 instead of 2.26 because 2.21 is the version on CRAN. So I would try to test the package using rstan 2.21, before I submitted to CRAN. (but maybe I misunderstand something here)

  3. It seems possible that you could get by with specifying C++14 as a requirement, because the note now says “drop C++14 unless it is essential”. My worry about trying that is the possibility of your package going to CRAN purgatory, where it is not accepted, you’re not sure whether it will be manually checked, and you are not sure when to email them about it.

1 Like

I think the best advice here is to remove any C++ spec from your DESCRIPTION and to remove the src folder so that it is auto-generated by rstantools on install.

Then the message to CRAN is that the current C++14 specification is entirely set by rstantools and will be resolved by the next version. The aim here being to move the burden from the multiple individual packages to just rstantools

@jonah and @wds15, does that seem like something acceptable for CRAN?

1 Like

It sounds totally fine to me…it’s just that CRAN must waive this. This sort of infrastructure package isn’t really a standard package.

As I am myself being affected by the C++ issues I would appreciate a quick resolution of the matter. So what is the timeline to publish the update rstantools to CRAN?

Right now I have to use hacks as the ones I outlined above… but that one also has some side-effects.

The RBesT package does not have a src folder nor a Makevars file…however these get generated from rstantools and as a result these files are part of my package and get checked. For now CRAN complains about the C++ thing and won’t accept the package. So there is some urgency here (at least for me, since the current RBesT on CRAN uses C++17 which is not the right thing and causes issues).

1 Like

I never found rstantools reliable enough, always turned out easier to setup my packages (ctsem and bigIRT) manually. Don’t mind changing if needed but have some scepticism that this is the solution…

@jonah and @bgoodri I’ve updated the rstantools PR with the added Boost CPP flags from the CRAN note mentioned above. I’ve also run reverse-dependency checks with the changes and all have passed.

3 Likes

If you have issues with reliability/configuration can you open an issue on Github with more info? Then we can ideally make the package more stable for all

2 Likes

You mean reverse dependency checks for all the R packages? Thank you! I can submit the update to CRAN soon if Ben is also ok with the changes. I’ll respond more on GitHub.

1 Like