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

[Toby Hocking]

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>
wrote:

>
> 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
> anything).
>
> 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
>
> https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/
> (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
> automatically).
>
> 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.
>
> Best
> Tomas
>
> >
> > 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)
> 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
> >     <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
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]