autoconf-archive-maintainers
[Top][All Lists]
Advanced

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

Re: --with and --enable to give paths


From: Dustin J. Mitchell
Subject: Re: --with and --enable to give paths
Date: Sun, 4 Oct 2009 14:11:46 -0400

On Sun, Oct 4, 2009 at 1:00 PM, Reuben Thomas <address@hidden> wrote:
> What's the difference between:
>
> ./configure --with-foo=PATH
>
> and
>
> ./configure CPPFLAGS="-I PATH"
>
> in this respect? They're both global settings for a particular build.

No -- one affects all invocations of the compiler for that project.
The other might affect only one invocation, perhaps via

AM_CPPFLAGS=-I $FOODIR/include

in foowrap-src/Makefile.am

> In any case, I was thinking specifically about libraries and headers;
> I confess I haven't thought about other cases.

And this is generally a problem with autoconf -- it was designed and
continues to be conceptualized as a way to uncover configuration for
*one* executable that needs to compile and link against a few other
libraries.  In one case I can think of, I need libcurl to link against
one particular plugin, but not the executable that loads that plugin.
If the libcurl macro edits $LIBS and $CPPFLAGS, then I need to wrap it
to save those vars, diff them, and store the new flags in
$LIBCURL_LIBS and $LIBCURL_CPPFLAGS [1].  The situation is even worse
if I have to try to extract the libcurl-related preprocessor and
linker flags from LDFLAGS and CPPFLAGS (maybe with a regex like
/-[a-zA-Z] .*curl.*/?).

I get in trouble with packaging people all the time for over-linking
Amanda: most of the libs Amanda uses are linked to every executable
and shared object, even when not necessary.  But to do anything else
with autoconf is a lot of work!  You'll note that AC_CHECK_LIB is
among the culprits here.

I realize I'm taking this off-topic, but I'm really making a more
general point -- autoconf needs to provide tools that can be used as
specifically as possible, by putting unique pieces of information in
unique places (e.g., libcurl libs in $LIBCURL_LIBS).  It is then up to
the developer to use that information as widely or narrowly as desired
(e.g., LIBS="$LIBCURL_LIBS $LIBS").

Dustin

[1] I don't mean to heap blame on libcurl, and in fact I think the
libcurl macro does things the way I want -- it's just an example.

-- 
Open Source Storage Engineer
http://www.zmanda.com




reply via email to

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