identically emulate CRAN builds?

[jayhesselberth]

Is there a way to use r-appveyor to identically emulate builds on CRAN during package submission?

I have a package that uses Rcpp and builds fine with all three compilers on appveyor, but generates warnings on CRAN (preventing its acceptance by the CRAN maintainers).

I'd like to be able to generate the errors locally for debugging. The package uses C++11 and links to dplyr. I intend to also file a dplyr issue, but wanted to try to figure out what might be done before. I get several of the following compiler warnings on CRAN, but not on appveyor:

*** arch - i386
d:/Compiler/gcc-4.9.3/mingw_32/bin/g++  -std=gnu++11 -I"D:/RCompile/recent/R/include" -DNDEBUG -I../inst/include   -I"d:\RCompile\CRANpkg\lib\3.4/Rcpp/include" -I"d:\RCompile\CRANpkg\lib\3.4/BH/include" -I"d:\RCompile\CRANpkg\lib\3.4/dplyr/include" -I"d:/Compiler/gcc-4.9.3/local330/include"     -pedantic -O2 -Wall  -mtune=core2 -c RcppExports.cpp -o RcppExports.o
In file included from d:\RCompile\CRANpkg\lib\3.4/dplyr/include/dplyr.h:11:0,
                 from ../inst/include/valr.h:5,
                 from RcppExports.cpp:4:
d:\RCompile\CRANpkg\lib\3.4/dplyr/include/tools/all_na.h:15:40: warning: ISO C99 requires rest arguments to be used
     RCPP_RETURN_VECTOR( all_na_impl, x ) ;
                                        ^
d:\RCompile\CRANpkg\lib\3.4/dplyr/include/tools/all_na.h:15:40: warning: ISO C99 requires rest arguments to be used
d:\RCompile\CRANpkg\lib\3.4/dplyr/include/tools/all_na.h:15:40: warning: ISO C99 requires rest arguments to be used
d:\RCompile\CRANpkg\lib\3.4/dplyr/include/tools/all_na.h:15:40: warning: ISO C99 requires rest arguments to be used

Here's the full build log via devtools::build_win(): https://gist.github.com/jayhesselberth/716f36642d6c8e6248553565109168fc

[krlmlr]

Please be aware that the C++ interface of dplyr is unstable at best. What's the purpose of including dplyr headers?

dplyr isn't tested with C++11. I'm not sure why the compiler complains about "C99" for a C++ source file, too.

To your original question: You probably need to set GCC_PATH to mingw_64 (or mingw_32), as detailed in the README: https://github.com/krlmlr/r-appveyor#readme.

[jayhesselberth]

The package is building cleanly using all three of the GCC_PATH options (gcc-4.6.3, mingw_64 and mingw_32).

https://ci.appveyor.com/project/jayhesselberth/valr/build/1.0.56

Only CRAN generates the warnings. I gather you expect r-appveyor and CRAN to be identical, then?

Re: using dplyr C++ bindings. Perhaps an early design mistake, but so far haven't had too many issues. GroupedDataFrame, SlicingIndex and DataFrameSubsetVisitor on the Rcpp side are very useful. I suppose my rationale was at least GroupedDataFrame had been put in the Rcpp namespace, which suggested to me it was somewhat stable. I see your recent changes to SlicingIndex and intend to keep up with those modifications. You're suggesting I bail on using dplyr C++? Painful, but maybe wise at this point.

[krlmlr]

This is very strange indeed. If you look at the artifacts of your build, specifically at 00install.log, the flag -std=c++0x seems to be used for installing the package. Perhaps you could add PKG_CXXFLAGS to your Makevars file to resolve the issue? (Strange that CRAN doesn't require it, though.)

I'd be glad to work with you (as the currently only user ;-) ) on the definition of a clean API, which should perhaps be moved to tibble. What else would belong there? (Putting GroupedDataFrame into Rcpp looks like a convenience solution to a namespace problem to me.)

[jayhesselberth]

I was able to get the desired CRAN behaviour by augmenting my local compilation with the CRAN default g++ parameters. Adding this line to my Makevars gives me the warnings that CRAN generates:

PKG_CXXFLAGS = -Wall -pedantic

Thanks to a random comment by Joe Cheng on a blog post.

Perhaps you should add a note somewhere on the r-appveyor README that suggests adding these parameters to faithfully emulate CRAN win-builder; it might save users some pain down the line. That same note should also indicate that those flags generate Non-portable flags in variable 'PKG_CXXFLAGS' warnings upon R CMD CHECK, so would probably have to be removed prior to CRAN submission.

I have further tracked my particular error down to changes in the RCPP_RETURN_VECTOR macros in Rcpp that were incorporated into the latest version (v0.12.7). I get these warnings using Rcpp v0.12.7, but I note that compilation of my package against Rcpp v0.12.6 (the previous version) eliminates the warnings.

Variadic macros seem like dark magic to me. Perhaps you have a suggested fix on the dplyr side? I think the warning boils down to a macro argument that RCPP_RETURN_VECTOR is expecting (using v0.12.7), but doesn't have to be provided in v0.12.6. I'm going to move this discussion to a dplyr issue.

Re: a stable dplyr C++ API. This would be amazing, but don't have a lot of time to contribute. I would follow a discussion in the dplyr issues if you were to start one.

[krlmlr]

r-appveyor could easily create .R/Makevars with

PKG_CXXFLAGS=-Wall -pedantic
PKG_CFLAGS=-Wall -pedantic

@jimhester: Should r-travis also do this, or is this perhaps implemented already?

[jimhester]

Just added with https://github.com/travis-ci/travis-build/pull/885, I would suggest doing something similar with a site Makevars on appveyor rather than using the user ~/.R/Makevars directly.