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

[SN248]

Thank you Tomas and Sokol for your suggestions.

Based on Tomas' suggestion, it seems the best way forward would be to first
request CRAN maintainers to install libsbml on the CRAN machines. It is
quite straightforward to install the library from the instructions provided
online. If the installation fails on a particular architecture, I should
try bundling the source code and creating the static libraries.

Thanks again for your help.
Satya

On Thu, May 13, 2021 at 2:28 AM Tomas Kalibera <tomas.kalibera using gmail.com>
wrote:

>
> 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]]
> >
> > ______________________________________________
> > R-package-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]