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

[MTurgeon]

Hi Ege,

For writing to standard output/error, you can use Rcout or Rcerr 
(defined by Rcpp; they even have a vignette showing how to use it in the 
Rcpp gallery). Alternatively, if you're using C code, you can replace 
printf by Rprintf (this is explained in Writing R extensions, section 6.5).

For abort, you can use error() instead (this is documented in WRE, 
section 6.2).

Hope this helps,

Max

On 2016-08-03 03:36 PM, Ege Rubak wrote:
> Hi,
>
> I would like to port Google's s2-library for spherical geometry (see 
> e.g. https://github.com/micolous/s2-geometry-library for a fork on 
> GitHub). It is not a standard library that can easily be installed on 
> various systems, so I would like to include the source code in the R 
> package. The catch is that I would like to modify the source code as 
> little as possible :-)
>
> I have package everything and added configure scripts and a tiny 
> R-function that calls one of the C++-functions (using the antiquated 
> .C interface for now -- that will of course be changed) in this repo:
> https://github.com/spatstat/s2
>
> It compiles into a working package on Ubuntu (travis-ci + my laptop), 
> OSX (travis-ci), and Windows (appveyor + my surface pro), but R CMD 
> check produces some warnings (and a note about the size of the shared 
> object, but I assume that is less important).
>
> 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'm not very used to writing C/C++ code, but I guess 1. can be fixed 
> by a few sed commands with the replacement headers and corresponding 
> new function names. Point 2. can probably also be fixed with a 
> reasonable effort, but I haven't investigated yet, and I would like an 
> opinion from the list before spending more time on this. In more 
> generality the question could be phrased something like:
>
> "When including C++ code from an upstream library which you do not 
> control should R CMD check be completely spotless or is some 
> flexibility to be expected in these circumstances?"
>
> Cheers,
> Ege
>
> PS: Extra question (prehaps particularly aimed at Dirk): When I will 
> actually start to use the C++ library I expect it could be beneficial 
> to use Rcpp. I have seen RcppModules mentioned somewhere, and I wonder 
> if such an external C++ library would make sense to interface via 
> RcppModules (again aiming at changing upstream sources as little as 
> possible)?
>

-- 
-----------------------------------------------------------------

Maxime Turgeon, PhD candidate

Department of Epidemiology, Biostatistics and Occupational Health
McGill University