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

Tomas Kalibera tom@@@k@||ber@ @end|ng |rom gm@||@com
Thu May 13 08:28:11 CEST 2021

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 

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.


> Thanks
> Satya
> 	[[alternative HTML version deleted]]
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

More information about the R-package-devel mailing list