[R-pkg-devel] set pkg_config for 3rd party software

[Serguei Sokol]

On 05/09/2019 12:26, Martin Maechler wrote:
>>>>>> Sameh M Abdulah
>>>>>>      on Fri, 30 Aug 2019 18:50:55 +0000 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<path>  (the path used  by ' #include <...> ' statement)
> 
> and for linking a correct  -L<path>.
> 
> 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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>