[R-pkg-devel] SystemRequirements: Berkeley DB STL

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
do
| I need to do to get this package (with compiled mac/windows binaries) on
| CRAN?
|
| This C++ library is relatively easy to install
|
https://github.com/tdhock/PeakSegPipeline/wiki/FAQ#installing-berkeleydb-stl
| 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
PKG_LIBS=-ldb_stl
| in my src/Makevars. Is that OK?

In short, no.

This is a messy topic, but in the briefest of nutshells you have an
external
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
systems
   => or if you can do the work, install it via your package (nloptr does
that)
      (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.

But then you still need Windows (where Uwe is generally equally helpful,
but
not everything builds on Windows, he has zero spare time to build it for
you
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.

And then you need macOS.  I will not say much more in order to remain
polite
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
of
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
"bad
package" stigma.  I still have that problem with a few other packages of
mine
lacking a macOS library at CRAN, and it is "difficult" to understate by
some
order.

Oh, and did I mention the joy that is Solaris?

In short, this is complicated. See fortunes::fortune(356) (h/t Doug Bates).

Dirk

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