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@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
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
