[R-pkg-devel] R package with external C++ library

Kevin Ushey kevinushey at gmail.com
Thu Aug 4 00:10:45 CEST 2016


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 <rubak at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



More information about the R-package-devel mailing list