Re: nonstandard library directories

[Micah J. Cowan]

On Thu, Jul 13, 2006 at 09:29:57AM -0600, Ed Hartnett wrote:
> address@hidden (Bob Proulx) writes:
> 
> > Edward L Platt wrote:
> >> Peter O'Gorman wrote:
> >> >Probably like this instead:
> >> >./configure CPPFLAGS="-I/sw/include" LDFLAGS="-L/sw/lib"
> >>
> >> Thanks for the help everybody.  It looks like the problem I was  
> >> really having was that I'm compiling for os x and gnu gettext and  
> >> related functions are in a separate library (libintl) so needed to  
> >> use the following environment:
> >> 
> >> export CFLAGS="-I/sw/include"
> >> export LDFLAGS="-L/sw/lib -lintl"
> >> export CXXFLAGS=$CFLAGS
> >> export CPPFLAGS=$CXXFLAGS
> >
> > It is much better to pass those as arguments to configure rather than
> > as environment variables.  Because then they will be used during
> > recheck operations and things like that.  Better to do it the way
> > Peter's example showed:
> 
> Excuse me, but what are "recheck operations?"
> 
> I have to give advice to a wide user base about how to do this, so I
> want to make sure I understand why doing this on the configure command
> line is better than setting environment variables.

Recheck operations probably refers to running ./config.status --recheck.
This reruns ./configure with all the arguments that were passed to it
before. It's mostly used when the configure script has changed, and you
want to update your configuration settings without changing /how/ it's
configured.

However, config.status doesn't detect changes in the environment, so the
configuration /will/ have changed, and the build environment might
become inconsistent, forcing the builder to start over again.

(To group:) Is this still true? The manual (for version 2.59, in section
"Setting Output Variables") seems a little inconsistent: it appears to
both claim that "it is impossible for [configure] to notice" when a
precious variable in the environment has changed, and that it will check
the environment "for consistency between two `configure' runs." It goes
on to demonstrate that ./config.status will remember precious variables
set in the environment. What exactly, then, is the hazard of setting it
in the environment these days?

> And what about the case where you set the value before ./configure?
> 
> CPPFLAGS=-Dsomething ./configure

This is exactly equivalent to exporting it first, as far as configure
will see. It temporarily sets CPPFLAGS as an environment variable
("exports" it) before running configure. It has the same problems.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/