Re: [R-pkg-devel] set pkg_config for 3rd party software
On Thu, Sep 5, 2019 at 12:27 PM Martin Maechler wrote: > Now what is the officially / best way to have either 'configure' > or Makevars.{in,win} use the 'pkg-config' information > *dynamically*, i.e., > if I update my MPFR from 4.0.1 to 4.0.2 the newer 4.0.2 is found ? I don't know what is best, but here are three alternatives: * Use PKG_CHECK_MODULES which sets up default variables with _CFLAGS and _LIBS suffix after searching for a library with pkg-config, c.f. https://autotools.io/pkgconfig/pkg_check_modules.html * Call pkg-config by hand in configure.ac (and hence configure). Example: https://github.com/eddelbuettel/rcppredis/blob/master/configure.ac#L47-L60 * Call pkg-config within an "Anticonf" configure script. Example: https://github.com/jeroen/curl/blob/master/configure#L16-L24 cheerio ralf __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
On 05/09/2019 12:26, Martin Maechler wrote: Sameh M Abdulah on Fri, 30 Aug 2019 18:50:55 + writes: > Hi, > I recently asked some questions about my R package which were well responded by Dirk. > I have another question related to pkg_config path, > I am using this command to add the installation path to the PKG_CONFIG_PATH so that all cmake commands can get the required libraries from this path, > Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':')) > Is there a simple way to set this path without explicitly calling this line before installing my package? OR is there any other path that I can use so that all software CMake commands can easily find the required libraries? > --Sameh Not an answer, but a #METOO with a hopefull very related question, also on using 'pkg-config' (Note: "-", not "_" here) for package configuration. I'm maintainer of CRAN package Rmpfr (for arbitrary precise arithmetic..), https://cran.r-project.org/package=Rmpfr development & source on R-forge http://rmpfr.r-forge.r-project.org/ and https://r-forge.r-project.org/scm/viewvc.php/pkg/?root=rmpfr which "down there" is principally an interface to the GNU MPFR C library (which also needs the GNU GMP C library). I do have a Rmpfr/configure.ac from which to produce Rmpfr/configure which then ensures that both libraries (MPFR and GMP) are found and are "working". The 'configure' script then (supposedly, but not on Windows?) takes either src/Makevars.in (non-Windows) or src/Makevars.win (Windows) to produce src/Makevars which then is used during compilation of the C sources of my package. I have a small marginal remark about this. Makevars.win is not windows equivalent of Makevars.in but of plain Makevars (see https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-subdirectories ) On windows, you can use configure.win which in turn can use Makevars.win.in to produce Makevars.win. The latter will be used by make on that platform (see https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Configure-and-cleanup ) Best, Serguei. Notably it will contain '-lmpfr -lgmp' among the LDFLAGS in any case. Now back to the 'pkg-config' : The compiler *also* needs correct -I (the path used by ' #include <...> ' statement) and for linking a correct -L. Now, my main OS, Linux Fedora (as all other decent Linux distributions) does provide MPFR and GMP libraries (and include headers) as OS packages, installed in /usr/lib/ (actually /lib64 nowadays) and /usr/include respectively. However, for some reasons I don't know the *version* of the MPFR library that the OS provides is outdate (to my taste), and I'd really want a newer version of MPFR, which I easily install in a version of /usr/local/. *and* I also make sure that pkg-config --libs mpfr and pkg-config --cflags mpfr list the corresponding LDFLAGS and CFLAGS (the first giving -L/usr/local.../mpfr/4.0.1/lib -lmpfr -lgmp the 2nd -I/usr/local.../mpfr/4.0.1/include ) Now what is the officially / best way to have either 'configure' or Makevars.{in,win} use the 'pkg-config' information *dynamically*, i.e., if I update my MPFR from 4.0.1 to 4.0.2 the newer 4.0.2 is found ? My current setup would not even work on some platforms to really end up using my local version of MPFR instead of the system-wide OS default (using /lib64 and /usr/include/ and then which even with quite new Fedora 30 is still MPFR 3.1.6 .. much too old for some of the things I want). __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Single character in Fortran function and FCONE and FCLEN macros
On 3 September 2019 at 15:37, Tomas Kalibera wrote: | Yes, that seems to be an upstream problem. Maybe checking with the documentation for Armadillo documentation at http://arma.sourceforge.net/docs.html (large page, see about the various #define in config.hpp near the bottom) could be of help. Might be worth trying to set ARMA_DONT_USE_FORTRAN_HIDDEN_ARGS. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] set pkg_config for 3rd party software
> Sameh M Abdulah > on Fri, 30 Aug 2019 18:50:55 + writes: > Hi, > I recently asked some questions about my R package which were well responded by Dirk. > I have another question related to pkg_config path, > I am using this command to add the installation path to the PKG_CONFIG_PATH so that all cmake commands can get the required libraries from this path, > Sys.setenv(PKG_CONFIG_PATH=paste(Sys.getenv("PKG_CONFIG_PATH"),paste(.libPaths(),"exageostat/lib/pkgconfig",sep='/',collapse=':'),sep=':')) > Is there a simple way to set this path without explicitly calling this line before installing my package? OR is there any other path that I can use so that all software CMake commands can easily find the required libraries? > --Sameh Not an answer, but a #METOO with a hopefull very related question, also on using 'pkg-config' (Note: "-", not "_" here) for package configuration. I'm maintainer of CRAN package Rmpfr (for arbitrary precise arithmetic..), https://cran.r-project.org/package=Rmpfr development & source on R-forge http://rmpfr.r-forge.r-project.org/ and https://r-forge.r-project.org/scm/viewvc.php/pkg/?root=rmpfr which "down there" is principally an interface to the GNU MPFR C library (which also needs the GNU GMP C library). I do have a Rmpfr/configure.ac from which to produce Rmpfr/configure which then ensures that both libraries (MPFR and GMP) are found and are "working". The 'configure' script then (supposedly, but not on Windows?) takes either src/Makevars.in (non-Windows) or src/Makevars.win (Windows) to produce src/Makevars which then is used during compilation of the C sources of my package. Notably it will contain '-lmpfr -lgmp' among the LDFLAGS in any case. Now back to the 'pkg-config' : The compiler *also* needs correct -I (the path used by ' #include <...> ' statement) and for linking a correct -L. Now, my main OS, Linux Fedora (as all other decent Linux distributions) does provide MPFR and GMP libraries (and include headers) as OS packages, installed in /usr/lib/ (actually /lib64 nowadays) and /usr/include respectively. However, for some reasons I don't know the *version* of the MPFR library that the OS provides is outdate (to my taste), and I'd really want a newer version of MPFR, which I easily install in a version of /usr/local/. *and* I also make sure that pkg-config --libs mpfr and pkg-config --cflags mpfr list the corresponding LDFLAGS and CFLAGS (the first giving -L/usr/local.../mpfr/4.0.1/lib -lmpfr -lgmp the 2nd -I/usr/local.../mpfr/4.0.1/include ) Now what is the officially / best way to have either 'configure' or Makevars.{in,win} use the 'pkg-config' information *dynamically*, i.e., if I update my MPFR from 4.0.1 to 4.0.2 the newer 4.0.2 is found ? My current setup would not even work on some platforms to really end up using my local version of MPFR instead of the system-wide OS default (using /lib64 and /usr/include/ and then which even with quite new Fedora 30 is still MPFR 3.1.6 .. much too old for some of the things I want). __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel