[R-pkg-devel] Passing CRAN checks for a package linking to a system library on CRAN machines

On 5/13/21 7:06 AM, SN248 wrote:

I am working on a package which provides an interface to the libsbml C++
library (http://sbml.org/Software/libSBML) in R. The source code of this
package (r2sbml) can be found at the following link

https://github.com/sn248/r2sbml

The package passes CRAN checks with `R CMD check` on my machine, but I do
have dependency (libsbml library) installed on my machine (OSX) with
headers and static libs at the usual locations, i.e., /usr/local/include
and /usr/local/lib. The package also passes CRAN check on a Windows

machine

with libsbml installed using Rtools40 and msys2. The DESCRIPTION file

lists

libsbml in SystemRequirements but `R CMD check` obviously fails on rhub
machines because there are no instructions to install libsbml first. As I
understand, I have the following options to pass checks on CRAN

1. Bundle the source code of libsbml into the package and make the static
libs on the fly. I don't really want to try this approach even though I
have used this approach before in another package as I think creating the
static lib is not as straightforward for this library because of the

large

number of files and complex dependency chart.

2. Include header files in the `inst` folder and pull the static libs

from

rwinlib github (assuming the libs can be posted there). I am not sure if
this approach will work on all platforms on which CRAN checks take place.

3. Somehow include instructions to install libsbml on CRAN machines (I

have

no idea how to do this), or request CRAN maintainers to install libsbml
with header files and libs at usual locations (i.e., /usr/local/include

and

/usr/local/lib).

I am sure some version of this question has been asked before as there

are

many packages which interface with C/C++ libraries listed as
SystemRequirements, but I could not find a clear answer to this aspect,
i.e., passing checks on CRAN machines.

Any guidance here and pros/cons of the above mentioned approaches will be
very helpful.

I think the best way for maintenance and end users is when the libraries
are part of common software distributions R is used with on each
platforms, which are also installed on CRAN machines. For Linux these
are popular distributions including Debian, Ubuntu, Fedora. For Windows
this is customized msys2 (rtools) and customized mxe. For macOS this is
a custom distribution ("recipes").

So, if your library is already present in those distributions, but not
installed on some of the CRAN machines, I'd simply ask for it to be
installed - the installation is trivial in that case, this is what the
distributions are for.

If the library is not present in those distributions, the next best I
think is to contribute it to them. In case of Windows, ideally
contribute also to the upstream vanilla distributions, not just to the
customized versions for R. This would allow most people to benefit from
your contribution, and the additional burden on CRAN maintainers (who
have to deal with many thousands of packages) would be minimized.

If all that failed, and the license allows, one can include the source
code of the library into the package, but that creates burden on users
as well as maintainers (of the package, but also the repository). It may
create confusion about the configuration due to duplication between
packages. It creates burden for repository maintainers. It takes
additional time on installation (particularly some libraries heavily
using C++ take forever to build, and repository maintainers do that very
often).

Downloading pre-compiled binaries (static libraries) at installation
time is the worst option in my view. It is non-transparent,
non-repeatable, and the binaries may be incompatible (e.g. on Windows
all object files have to be built for the same C runtime). It makes
maintenance of R much harder, currently the transition from MSVCRT to
UCRT on Windows.

Best
Tomas

Thanks
Satya

      [[alternative HTML version deleted]]