[R-pkg-devel] Wrapping a third-party c++ library
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. Thanks, Sean signature.asc Description: Message signed with OpenPGP using GPGMail __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrapping a third-party c++ library
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. 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. Easiest 'dirty' solution: throw all source files into your package's src/ and hope for the best. Works for small packages. Long story short: for something complicated like this, maybe a Docker container is the best you can do :-/ Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrapping a third-party c++ library
Thanks for the reply and feedback, Dirk. > On Aug 23, 2016, at 10:59 AM, Dirk Eddelbuettel 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 | e...@debian.org signature.asc Description: Message signed with OpenPGP using GPGMail __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [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 wrote: > Thanks for the reply and feedback, Dirk. > > > On Aug 23, 2016, at 10:59 AM, Dirk Eddelbuettel 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 | e...@debian.org > > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Wrapping a third-party c++ library
On 23 August 2016 at 11:13, Sean Davis wrote: | Thanks for the reply and feedback, Dirk. Pleasure! | > On Aug 23, 2016, at 10:59 AM, Dirk Eddelbuettel wrote: | > Local shared libraries is hard(est). I would not start there. I missed one line here: "Hard(est) because you have to communicate with dynamic linker." For eg RInside we do that and encode the path via rpath, but that is eg frowned upon by Debian because it makes your binary (or library) non relocatable as those paths remain fixed../ | > 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. Eeeek. | > 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. Sadly, it really is hard, and made harder by the fact that we have some many choices -- and then OS-depedencies. I have been thinking about creating a tutorial for Rcpp users on this but so far have not yet figured out how to do it all well enough to be worth it. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
