[R-pkg-devel] Wrapping a third-party c++ library

[Sean Davis]

Thanks for the reply and feedback, Dirk.

> On Aug 23, 2016, at 10:59 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
> 
> 
> hi Sean,
> 
> On 23 August 2016 at 09:13, Sean Davis wrote:
> | I am trying to wrap a third-party toolkit that provides a C++ API.  The code is open source and includes a license that allows me to include it directly in an R package.  Right now, I am happy if I can get ANY build (linux, windows, or Mac) working.  The rough build process looks like that given here (starting at the highlighted line):
> |
> | https://github.com/seandavi/SRA2R/blob/master/inst/docker/install_ngs_sdk.sh#L22
> |
> | Unfortunately, these configure scripts are not standard autoconfig flavor, so they seem pretty fragile (even with a —prefix, they try to install stuff into system libraries).  My goal is to include the source of the two partner libraries and build shared libraries in the R installation hierarchy.  I simply do not have enough experience using configure scripts to know how to translate what I have noted above into something that would be expected to get the installation right in the r package directory and allow linking.
> |
> | Any concrete suggestions about how to move this forward are much appreciated.
> 
> Local shared libraries is hard(est). I would not start there.
> 
> System shared libraries is easy (just ask all the database packages, graphics
> formats packages etc pp) -- but you then push the burden onto your users to
> actually *have* these system libraries.  Not easy with "obscure" science stuff.

It is complicated further by the fact that the group who develops this software distributes it as binaries to many users.

> Middle ground: _static_ library in your package.  Tweak and bend the required
> libraries til they cooperate, then adjust.  This has been done since time
> immortal, see eg the Matrix package and its several subdirectories.  Still
> not trivial, but doable.

Probably beyond my patience level, but….

> Easiest 'dirty' solution: throw all source files into your package's src/ and
> hope for the best.  Works for small packages.

Yeah, I have tried that in the past and perhaps after some cleanup the code can get there.

> Long story short: for something complicated like this, maybe a Docker
> container is the best you can do :-/

Yeah, docker is what I have been living with for months and it is a great solution for development, but moving that paradigm the the standard scientific HPC environment just isn’t happening despite all the problems it would potentially bypass.

Nice to know that, while my R foo is limited compared to others on this list, I am not crazy to think that this might be hard.

Sean


> 
> Dirk
> 
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://stat.ethz.ch/pipermail/r-package-devel/attachments/20160823/e75a8a47/attachment.bin>