19/09/13 16:05, Ram?nas Gutkovas wrote:
On 9/19/13 4:47 PM, Alex Merry wrote:
On 19/09/13 15:14, David Matthews wrote:
I don't know how useful it will be in general, though. I've done a quick look and pkg-config doesn't seem to be installed on several set-ups I looked at including Mac OS X and Solaris.
I didn't really have a feel for its general prevalence outside the Linux world and agree that it may not be useful for all applications. A quick search suggests it should be straightforward to build though, e.g. https://github.com/LearnBoost/node-canvas/wiki/Installation---OSX (though --with-internal-glib may be needed if glib is not present). Possibly even a single-command install, e.g. http://cduu.wordpress.com/2011/11/26/install-pkg-config-on-mac-os-x/ However, I doubt applications such as HOL4 would want to force this on those building them.
The other problem is that it is going to require the PC files to be written into /usr/lib/pkgconfig or some other non-user-writable directory. One of the problems I was trying to work round was the fact that many users of Poly/ML are running on systems that are managed centrally and they don't have root access. It's this that makes shared libraries a problem because libpolyml can't be installed to /usr/lib or /usr/local/lib. All this means that anyone distributing code, such as HOL4 or Metit that are intended to be built with poly, can't rely on pkg-config.
It should just be installed to $PREFIX/lib/pkgconfig; users can then export the environment variable PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig:$PKG_CONFIG_PATH before building the tool that uses Poly/ML, in much the same way that they have to set PATH=$PREFIX/bin:$PATH (or supply an absolute path to poly). pkg-config will then find the .pc file.
Yes, and more generally, once a build system has determined the location of poly it could set PKG_CONFIG_PATH within the build process.
Possibly $PREFIX/share/pkgconfig would be better installation location. One would want the property that when $PREFIX is /usr, the PC file is located in the default pkg-config path. This is $libdir/pkgconfig:$datadir/pkgconfig where libdir and datadir are determined by the installation location of pkg-config. pkg-config can report these:
[pclayton at rizzo ~]$ pkg-config --variable=pc_path pkg-config /usr/lib64/pkgconfig:/usr/share/pkgconfig
libdir is either .../lib or .../lib64 depending on the platform so datadir, which is .../share, avoids the difference.
On 9/19/13 4:47 PM, Alex Merry wrote:
pkg-config is mostly a Linux thing (although I suspect it's easily found on *BSD systems), so it's not so useful for Windows or the proprietary unices like OS X and Solaris.
pkg-config seems to have support for these platforms (mingw in the case of Windows). It would be useful to know how readily available it is via a package management system on those platforms.
19/09/13 16:05, Ram?nas Gutkovas wrote:
A possible option would also be to generate a shell script, say poly-config, and install on the same path as poly which would accept the same options as pkg-config. The script could be generated in case the pkg-config is not available. This would solve the portability issue for non linux systems.
Yes, or even a subset of the behaviour.
Standing back, there appear to be (at least) two levels here: 1. Indicating to a build system whether Poly/ML SO files are available so it can select suitable linker flags 2. Providing the required linker flags for any Poly/ML installation The first would suffice but the second would be nice.
Regards, Phil