Doesnt seem like the system package is worth it. Should the convention simply be to bundle the headers in the package then? What about package size - is there some limit to the size of included libraries/headers to consider for CRAN?
On Sat, 24 June 2023, 15:08 Simon Urbanek, <simon.urba...@r-project.org> wrote: > 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 <stephematic...@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@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel