Mike Castle <[EMAIL PROTECTED]> writes:
> On Tue, May 22, 2001 at 03:37:37PM -0700, Russ Allbery wrote:
>> Widespread support for such a feature in configure scripts would make
>> my life *significantly* easier. Currently I actually hack gcc to look
>> in both /usr/local and /usr/pubsw, and I'd love to get rid of that hack
>> but it makes building things a horrid pain.
> What about pkg-config?
> http://pkgconfig.sourceforge.net
> Instead of you having to remember what all /a:/b:/c paths to add, it's
> kept in a central database.
> It has a few problems, but it's only at version 0.5 so far.
Most things that work through central databases don't work all that well
for me. There are a lot of assumptions that go into databases like that,
and a surprising number of them (surprising to people who have not
maintained a large-scale distributed software installation) don't
generalize at all well.
What I'd love to see is a way to pass the configure script a whole list of
directories into which software may be installed, not just /usr/local and
/usr/pubsw but also /usr/pubsw/apps/db3 and /usr/pubsw/apps/openssl and
other directories that have a lib and include structure, and then have
configure check those directories for needed libraries, add the right -I
and -L flags, add the right -R or -Wl,-rpath or whatever flags to link
against shared libraries, and otherwise take care of all the mechanics
that I've seen dealt with in more --with-foo=PATH configure.in fragments
using more different techniques (many wrong in common situations) than I'd
care to remember.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
