[R-pkg-devel] Passing CRAN checks for a package linking to a system library on CRAN machines
tdhock5 @end|ng |rom gm@||@com
Tue May 18 19:54:55 CEST 2021
Hi Tomas, these are really helpful suggestions, which are not at all
discussed in the current Writing R Extensions, nor in CRAN Repository
Policy. Would you please consider adding this information to one of these
official sources of documentation?
On Fri, May 14, 2021 at 3:59 AM Tomas Kalibera <tomas.kalibera using gmail.com>
> On 5/14/21 4:19 AM, SN248 wrote:
> > 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.
> Please let me clarify, I am not suggesting that you ask CRAN team to
> create the distribution packages for you, but only to install an
> existing distribution package (in case they are not doing that already).
> The distribution package is usually a script which automatically
> downloads the software, builds it, picks up the results, adds some
> meta-data about dependencies, and archives them in a supported format.
> Someone has to create the distribution package, and I am suggesting that
> you as R package maintainer should do that, possibly getting help from
> other volunteers e.g even on the R-devel mailing list. The CRAN team
> would only add that package name to their list of installed packages (in
> case it is not there implicitly, i.e. they possibly won't have to do
> So first, I would should check for existing distribution packages. Most
> distributions have their own indexing/search support, but you can also
> look online as follows.
> For Linux distributions, there is e.g. pkgs.org for the first quick
> search (libsml-devel, libsbml-dev might be what you are looking for).
> For Windows, msys2 packages are here
> https://github.com/msys2/MINGW-packages/, rtools packages are here
> https://github.com/r-windows/rtools-packages (so there is
> mingw-w64-libsbml). MXE packages are here
> https://github.com/mxe/mxe/tree/master/src and the customized version
> for R is here
> (so upstream MXE doesn't have sbml, but the customized has libsbml).
> For macOS, recipes for R are here
> https://github.com/R-macos/recipes/tree/master/recipes and it does not
> have sbml library as far as I can see.
> So, if you wanted your package to use sbml, the best way would be to
> test it with the sbml package from all the distributions mentioned above
> (from Linux, at least the ones used by CRAN - Debian/Ubuntu, Fedora).
> Then, you would create a recipe (distribution package) for macOS, test
> it with your package, and contribute to the "recipes" above. When
> creating the recipe, look at other recipes to get the form, and look at
> sbml in the previously mentioned distributions to see how to
> download/build it (in addition to the online manual you mentioned).
> Once that is in, you could submit your package to CRAN, following the
> usual checks you do when submitting packages. And then, in case it
> failed on some of the CRAN machines, you could contact the individual
> maintainer and ask for installing that distribution package of the given
> name. In some cases it won't be necessary (the machines would already
> have the package, they may be installing all available packages
> This may sound like a bit of work, but that is the price for adding
> dependencies on native libraries, and someone has to do this work.
> Installing libraries manually on the check machines is not going to
> scale and may be too much burden for many end users, apart from
> difficulties with repeatability, maintenance, etc.
> > Thanks again for your help.
> > Satya
> > On Thu, May 13, 2021 at 2:28 AM Tomas Kalibera
> > <tomas.kalibera using gmail.com <mailto: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
> > <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 <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)
> > > 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
> > <mailto:R-package-devel using r-project.org> mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> > <https://stat.ethz.ch/mailman/listinfo/r-package-devel>
> [[alternative HTML version deleted]]
> R-package-devel using r-project.org mailing list
[[alternative HTML version deleted]]
More information about the R-package-devel