Re: [lmi] Working with certain third-party-libraries

[Vadim Zeitlin]

On Wed, 25 Oct 2006 15:04:16 +0000 Greg Chicares <address@hidden> wrote:

GC> * posix_fhs.make
GC> # EVGENIY I find no 'libxml++-config'.

 There is indeed no libxml++-config and libxml++ doesn't seem to use
pkg-config (the new, standard way of dealing with this problem for C
libraries in the Linux/Unix world) neither. And even if libxml++ developers
do add pkg-config in the future (which, sadly, seems unlikely as the
development of this library has stalled), it wouldn't help us as we don't
want to add dependencies on another package and OTOH no project is going to
start using project-config now that pkg-config is so widespread.

 So all I can suggest is to do nothing and rely on having libxml++ headers
and libraries in the standard locations or in CPPFLAGS/LDFLAGS environment
variables if they're installed elsewhere.

GC> * workhorse.make
GC> # A default installation places gnome xml-library headers here:
GC> #  libxml++: /usr/local/include/libxml++-2.6/libxml++
GC> #  libxml2:  /usr/local/include/libxml2/libxml
GC> #  libxslt:  /usr/local/include/libxslt
GC> # The first provides no '*-config' script at all. The last two provide
GC> # '*-config' scripts that don't respect an overriding $(prefix): they
GC> # apparently hardcode the paths above, so there's no point in calling
GC> # them.
GC> 
GC> I make the last comment because I configured with
GC>   prefix        := /c/usr/local
GC> [http://cvs.savannah.gnu.org/viewcvs/lmi/lmi/gwc/build_libxmlpp.make]
GC> but got
GC>   $/c/usr/local/bin/xml2-config --cflags
GC>   -I/usr/local/include/libxml2

 This is because you only pass prefix to make but xml2-config is generated
by configure. You should really do "configure --prefix=$(prefix)" instead
as it risks breaking other things as well.

GC> which is wrong because it has no '/c/'.

 Independently of the above, we really, really need to understand what's
going on with this '/c/'. It breaks everything here (I build with "make
system_root=''" to remove it) while you apparently can't build without it.
Why can't we use just /usr/local which doesn't suppose that mingw32 and
msys are installed in the root of the C: drive?

GC> * workhorse.make
GC> # Path to libraries from www.boost.org : most required boost libraries
GC> # are implemented exclusively in headers. It seems common in the *nix
GC> # world to leave those headers in the subdirectory of /whatever/src/
GC> # to which the boost distribution is extracted, probably because boost
GC> # does not put all its headers in an include/ subdirectory. But that
GC> # seems broken, so instead copy those headers to /usr/local/include .
GC> #
GC> # TODO ?? If the "common" practice above turns out to be universal,
GC> # then conform to it.
GC> 
GC> I'd like to get rid of that 'TODO ??' marker. Is the prevalent
GC> usage something like
GC>   -I /boost/boost_1_31_0/
GC> ?

 I don't think it's common to use the headers under "src" at all. This can
be done, of course, but it's hardly standard practice. When boost headers
come from a package (RPM, DEB or whatever), they normally go to just
/usr/include/boost, e.g. you don't need any special -I options for them if
you include them as <boost/shared_ptr.hpp>. If they're installed from
source, I believe the headers go to /usr/local/include/boost-x.y.z/boost by
default so you do need to use -I/usr/local/include/boost-x.y.z. So I'd
propose to, once again, simply do nothing about this and suppose that boost
headers are available in the default search path or that their directory is
specified in CPPFLAGS otherwise.

 Hope this helps to answer the above question,
VZ