[R-pkg-devel] Linking with software dependencies

[Dirk Eddelbuettel]

On 24 August 2019 at 18:16, Sameh M. Abdulah wrote:
| (1) My package requires a pre-installation of Intel MKL. Is there any way to include the MKL installation with the package.

This (or a related) question was discussed here (or on a related list ?)
very recently. The recommendation, that I concur with, was NOT to do
that. BLAS and LAPACK are standard interfaces. Strive to support these
standards, and if and only if you find a more performant alternative
installed, use that.  In short you need to write `configure` code to sort out
the environment into which your package tries to install.  Somewhat
moderately difficult but doable, and there are examples in other packages.
 
| (2) The package depends on several c-based software which I automatically install through the package installation. Linking with these dependencies is a necessity. Thus, I did a simple trick for that as follows,
| - I am installing all the software dependencies inside the default installation directory of the r-package then I am adding this path to the (PKG_CONFIG_PATH env) using this statement,
| Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':'))
| By this way, I will be sure that all libraries are accessible by the package.
| - Then, the installation can be done using install_git(url=" https://github.com/ecrc/exageostatR") for the GitHub repo.
| The problem that I need to avoid the manual setting of the (PKG_CONFIG_PATH) so that I can, for example, upload my package to CRAN and simplify the installation process. I am doing the dependencies installation using the package configure file which can be accessed through https://github.com/ecrc/exageostatR/blob/master/configure.

In short, this is a somewhat common but still difficult problem. We are
crossing over from R applications and packages to OS-level library provision.

A recent entry to this debate is an attempt in one CRAN package which (on
some platforms) discovers a YES or NO at installation time and then pivots
between a full and a rather limited installation.  To me this follows at best
the letter of the law, but not so much the spirit. Oh well.  It's on CRAN so
must be good enough.

Then again, the problem is difficult. I too have two candidate packages based
on solid work with other collaborators which I cannot get onto CRAN for lack
of library support, in particular on one somewhat non-maintained platform.
This is, to put it plainly, somewhat frustrating.

There is another approach which I have used with some packages.  Prebuild
libraries (or binaries) and fetch them at installation time.  Better than
nothing and results in working package but arguably still not ideal.

| (3) My package is only compatible with Linux and macOS. How to avoid CRAN windows checks.

That's easier.  Look at the documentation for the "OS_type:" field in the
DESCRIPTION file in the _Writing R Extensions_ manual that is your reference
for all these topics.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org