It looks like most of these usages of std::cout, std::cerr and abort are coming from the logging infrastructure:
https://github.com/micolous/s2-geometry-library/blob/master/geometry/base/logging.h If you wanted to make this work on CRAN, you could patch these files in a number of ways: You could replace calls to 'std::cout' with a helper function 'cout()', and 'std::cerr' with a helper function 'cerr()', to instead point to an output stream object that delegates to Rprintf and REprintf for logging. You can see a sample implementation of something like this in the infamous test obfuscation suite, testthat: https://github.com/hadley/testthat/blob/46d15dad93fc2bfca339963cb66ffb1a309fa8a0/inst/include/testthat/testthat.h#L58-L96 https://github.com/hadley/testthat/blob/46d15dad93fc2bfca339963cb66ffb1a309fa8a0/inst/include/testthat/testthat.h#L119-L129 Similarly, calls to 'abort()' could instead throw a C++ exception, which you would then catch at the top level with your R wrapper entrypoints, and forwarded to the user appropriately (e.g. with Rf_error called with no C++ objects on the stack). As for the use of deprecated C++ headers, you could patch those to instead use C++11's 'unordered_set' and 'unordered_map', or try getting similar classes from e.g. Boost. All in all, it would likely be a lot of work to get the package ready for a CRAN submission, but it's definitely doable. Finally, the CRAN policies state: Package authors should make all reasonable efforts to provide cross-platform portable code. Packages will not normally be accepted that do not run on at least two of the major R platforms. Cases for Windows-only packages will be considered, but CRAN may not be the most appropriate place to host them. So if compilation on Solaris really is a non-starter for some reason, I think you can indicate that you do not intend for your package to be used / distributed on Solaris (but you would probably have to provide sufficient justification during the submission). Cheers, Kevin On Wed, Aug 3, 2016 at 2:59 PM, Ege Rubak <ru...@math.aau.dk> wrote: > >>> The main things seem to be related to (travis log is at >>> https://travis-ci.org/spatstat/s2/jobs/149578339): >>> >>> 1. Deprecated C++ headers <ext/hash_set> and <ext/hash_map>. >>> >>> 2. Compiled code that calls entry points which might terminate R or >>> write to stdout/stderr. >>> >>> Is it hopeless to get on CRAN with warnings like these? >> >> >> I don't set CRAN policy, but I would say yes. Problem 1 limits your >> package to systems using compilers that support those antiquated >> headers; R tries very hard to be portable across many systems. Problem >> 2 makes R potentially unstable. >> > Thanks for the quick reply. The non-portability issue you mention has not > shown up so far but I was actually fearing it would show up once I (or more > likely CRAN) try to compile on solaris -- is there a way to test code on > solaris without bothering the brave CRAN souls? Anyway, I should probably > start executing some sed commands and see if I can get rid of the problem in > a fairly reproducible way. > Regarding problem 2 even if I never use the part of the C++ code that writes > to stdout etc. I guess it is impossible for CRAN to know this, so it makes > sense for them to be safe rather than sorry? > > /Ege > > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
