lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lmi] Working with certain third-party-libraries


From: Greg Chicares
Subject: [lmi] Working with certain third-party-libraries
Date: Wed, 25 Oct 2006 15:04:16 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

'wx-config' is extremely useful because wx is so extensively
configurable. Some (but not all) of the gnome xml libraries
have a similar feature, but it seems less useful. Let me
assemble below some makefile comments, then ask: what should
we do about this?

* posix_fhs.make
# EVGENIY I find no 'libxml++-config'. How should that
# library be handled here?
platform_libxml2_libraries := \
  $(shell xml2-config --libs) \
  $(shell xslt-config --libs) \

* workhorse.make
# A default installation places gnome xml-library headers here:
#  libxml++: /usr/local/include/libxml++-2.6/libxml++
#  libxml2:  /usr/local/include/libxml2/libxml
#  libxslt:  /usr/local/include/libxslt
# The first provides no '*-config' script at all. The last two provide
# '*-config' scripts that don't respect an overriding $(prefix): they
# apparently hardcode the paths above, so there's no point in calling
# them.

I make the last comment because I configured with
  prefix        := /c/usr/local
[http://cvs.savannah.gnu.org/viewcvs/lmi/lmi/gwc/build_libxmlpp.make]
but got
  $/c/usr/local/bin/xml2-config --cflags
  -I/usr/local/include/libxml2
which is wrong because it has no '/c/'.

For autotools, I guess this is okay as long as $prefix
is '/usr/local'. The hand-written makefiles hardcode a
similar assumption. Is there any reasonable alternative?

BTW, changing the subject, near the above-quoted block I see:

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

I'd like to get rid of that 'TODO ??' marker. Is the prevalent
usage something like
  -I /boost/boost_1_31_0/
?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]