[R-pkg-devel] SystemRequirements: Berkeley DB STL
tdhock5 @ending from gm@il@com
Wed Oct 24 18:47:35 CEST 2018
Hi Dirk thanks for the helpful response.
On Wed, Oct 24, 2018 at 5:09 AM Dirk Eddelbuettel <edd using debian.org> wrote:
> On 23 October 2018 at 14:02, Toby Hocking wrote:
> | I would like to put the https://github.com/tdhock/PeakSegDisk package on
> | CRAN. This package needs Berkeley DB C++ Standard Template Library. What
> | I need to do to get this package (with compiled mac/windows binaries) on
> | CRAN?
> | This C++ library is relatively easy to install
> | but probably too big (tar.gz source code is 43MB) to include in the R
> | package, so I have indicated this external library dependency in the
> | SystemRequirements field of DESCRIPTION. I have also put
> | in my src/Makevars. Is that OK?
> In short, no.
> This is a messy topic, but in the briefest of nutshells you have an
> library here which needs linking. That makes it complicated.
> A short road map (in increasing order of complexity) about the situation:
> - a small external library shipped just as headers, eg catch2, is easiest:
> => just include the header file
> => maybe even package the header file up in a package so that other
> packages can use it
> - a small external library ie just a few files is doable with little work:
> => just include it in your src/ directory
> => or maybe one level below src/ and have Makevars build it
> (which is something I just did to one of my packages)
> - a small-to-medium library typically installed externally gets harder
> => you are at the mercy of CRAN to have THAT LIBRARY on ALL of their
> => or if you can do the work, install it via your package (nloptr does
> (nloptr is extra-special because it then also exports 10 or so C
> entry points)
> - a large and complex library is really difficult
> => like the last point, only worse
> These (three to) four approaches could be split up further, eg by C versus
> C++, or by 'do you want other CRAN packages to use it too or not' etc.
> Here, you are at the last point. You have library that is
> a) large
> b) reasonably uncommon
> c) available in some but not other places
> As your README states, it exists for Debian/Ubuntu so you could (privately)
> ask Kurt to install it on his machines which he will probably do. A start.
I have emailed Kurt about this.
> But then you still need Windows (where Uwe is generally equally helpful,
> not everything builds on Windows, he has zero spare time to build it for
> and we have no mechanism to get it to him -- or maybe we do via Jeroen's
> rwinlibs -- to be checked). So a possible roadblock.
Judging from Uwe's non-response to my email requests, Jeroen's rwinlibs may
be a better option -- but what is that? I am not familiar with rwinlib.
Where are the docs?
> And then you need macOS. I will not say much more in order to remain
> and civil, but if you check the archives of this list and r-devel you will
> find me _begging_ a few weeks ago to be given a handle to turn off builds
> a package of mine because it could never have its libraries on macOS yet it
> would still always attempt to build on macOS yielding me two ERROR and a
> package" stigma. I still have that problem with a few other packages of
> lacking a macOS library at CRAN, and it is "difficult" to understate by
I emailed Simon about this and he added to his recipes so hopefully that
> Oh, and did I mention the joy that is Solaris?
In theory Solaris should not be hard -- the installation from source is
pretty much a standard configure && make && make install.
curl -OL http://download.oracle.com/berkeley-db/db-6.2.23.NC.tar.gz
tar xf db-6.2.23.NC.tar.gz
../dist/configure --prefix=$HOME --enable-stl
BTW in response to Hong: sorry for linking to the wrong wiki page -- in
fact PeakSegDisk does NOT depend on any UCSC tools. Just Berkeley DB STL
> In short, this is complicated. See fortunes::fortune(356) (h/t Doug Bates).
> http://dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
[[alternative HTML version deleted]]
More information about the R-package-devel