Problems with the new 1.4.0 build chain for Stan packages

[paul-buerkner]

While trying to migrate one of my Stan based R packages using rstantools 1.4.0, I stumbled upon multiple problems during the build process on Windows.

• While compiling, g++ complains about not finding file stan_files unless one already provided the names of the Stan files when running rstan_package_skeleton instead of adding them manually later on. The solution to manually amend the Makevars files is obvious in restrospect, but might still confuse many developers first trying to build an R package based on Stan. Do you already point developers to this potential problem?

• The current build chains expects license.stan to be in stan_files/pre, but rstan_package_skeleton puts it in stan_files/chunks.

• The point Be sure to import all of Rcpp and methods in the NAMESPACE file. in the Read-and-delete-me file is confusing to me, since both Rcpp and methods are on depends in the DESCRIPTION. I think it would be better to have at least Rcpp only in imports in the DESCRIPTION in order not to pollute the global env, but I am sure you have good reasons for the current way of doing it.

• SOLVED: On my machine, multiple cores still don't work as described in http://discourse.mc-stan.org/t/using-the-cores-argument-in-a-stan-based-r-package-with-precompiled-models/2236/8. EDIT: It only fails when building the package with "Build & Reload", which is admitedly a minor problem.

[dmenne]

I strongly support @paul-buerkner - the first point has bugged me over and over.

[jgabry]

@paul-buerkner Sorry for the slow response to this. We're going to release another rstantools soon and we should address some of these issues. There's a PR to add a new vignette walking through the process of making an actual package #15, so if there's anything not in that PR that you think would be good to add feel free to suggest it! We'll also be updating rstan_package_skeleton so that it avoids some of these problems.

[jgabry]

fixed in efbd674