[R-pkg-devel] Wrapping a third-party c++ library
Remember there are no rules for a configure script, there is only the tradition that it is a script you invoke prior to make. "Hand-written" configure scripts can do anything they want. In this case, I had a 2s look at the configure script in the ngs project which ultimately are a series of "konfigure.perl" scripts which may be hand written. It is hard to even know what options the script supports without reading the code. My perl is rusty but the perl script seems to reference build-prefix and prefix. Also, see the wiki https://github.com/ncbi/ngs/wiki/Building-and-Installing-from-Source You should look carefully at ./configure --help, but I am sure you know all this. This could indeed be painful. Probably doable, assuming infinite time though. Best, Kasper
On Tue, Aug 23, 2016 at 11:13 AM, Sean Davis <seandavi at gmail.com> wrote:
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):
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
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel