[R-pkg-devel] Convention or standards for using header library (e.g. Eigen)

Simon Urbanek @|mon@urb@nek @end|ng |rom R-project@org
Sat Jun 24 07:08:23 CEST 2023


Stephen,

If you want to give the system version a shot, I would simply look for pkg-config, add the supplied CPPFLAGS to the package R flags if present and then test (regardless of pkg-config) with AC_CHECK_HEADER (see standard R-exts autoconf rules for packages). If that fails then use your included copy by adding the corresponding -I flag pointing to your supplied copy. You should not download anything as there is no expectation that the user has any internet access as the time of the installation so if you want to provide a fall-back, it should be in the sources of your package. That said, there is nothing wrong with ignoring the system version especially in this header-only case since you can then rely on the correct version which you tested - you can still allow the user to provide an option to override that behavior if desired. 

Cheers,
Simon



> On Jun 23, 2023, at 10:08 PM, Stephen Wade <stephematician using gmail.com> wrote:
> 
> I recently submitted a package to CRAN which downloaded Eigen via Makevars
> and Makevars.win. My Makevars.ucrt was empty as I noted that Eigen3 is
> installed by default (however, this doesn't ensure that a version of Eigen
> compatible/tested with the package is available).
> 
> The source is currently on github:
> https://github.com/stephematician/literanger
> 
> Here is the Makevars
> 
> $ more src/Makevars
> # downloads eigen3 to extlibs/ and sets include location
> PKG_CPPFLAGS = -I../src -I../extlibs/
> .PHONY: all clean extlibs
> all: extlibs $(SHLIB)
> extlibs:
>         "${R_HOME}/bin${R_ARCH_BIN}/Rscript" "../tools/extlibs.R"
> clean:
>         rm -f $(SHLIB) $(OBJECTS)
> 
> The details of `extlibs.R` are fairly mundane, it downloads a release from
> gitlab and unzips it to `extlibs`.
> 
> CRAN gave me this feedback:
> 
>> Why do you download eigen here rather than using the system version of
>> Eigen if available?
>> 
>> We asked you to do that for Windows as you did in Makevars.ucrt. For
>> Unix-like OS you should only fall back (if at all) to some download if
>> the system Eigen is unavailable.
> 
> The problem is I'm not sure what a minimum standard to 'searching' for a
> system version of Eigen looks like. I also note that packages like
> RcppEigen simply bundle the Eigen headers within the package (and its
> repository) which will certainly ignore any system headers.
> 
> I would like a solution that would keep CRAN happy, i.e. i need to meet
> some standard for searching for the compiler flags, checking the version of
> the system headers, and then falling through to download release if the
> system headers fail.
> 
> 1.  For each platform (Unix, Windows, OS-X) what tool(s) should be invoked
> to check for compiler flags for a header-only library like Eigen? e.g.
> pkg-config, pkgconf? others?
> 2.  What is a reasonable approach for the possible package names for Eigen
> (e.g. typically libeigen3-dev on Debian, and eigen3 on arch, homebrew,
> others)? Is this enough?
> 3.  If pkg-config/pkgconf (or others) are unavailable, what is a reasonable
> standard for checking if the library can be built with some reasonable
> guess for the compiler flags (probably empty) - I assume I would need to
> try to compile a test program (within Makevars)?
> 4.  Following on from 3... would a package need to check (again via a test
> program) that the _system_ headers have the correct version (e.g. some
> static assert on EIGEN_WORLD_VERSION), and if that fails _then_ download
> the release from gitlab?
> 
> Any and all advice would be appreciated.
> 
> Kind regards,
> -Stephen Wade
> 
> 	[[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