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

[Kasper Daniel Hansen]

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

	[[alternative HTML version deleted]]