apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: svn commit: r560688 - /apr/apr-util/trunk/build/apu-conf.m4
Date Sun, 29 Jul 2007 23:45:57 GMT
On Jul 29, 2007, at 7:54 AM, Justin Erenkrantz wrote:

> On 7/29/07, Joe Orton <jorton@redhat.com> wrote:
>> Hmm, why the save/restore of CPPFLAGS/LDFLAGS?  This is only  
>> necessary
>> when there is some failure case where the changes made will not  
>> persist
>> until build time, so should not affect subsequent tests.  For  
>> cases like
>> e.g. --with-expat=/path, the path modifications will persist to build
>> time, so should be left as-is; they have a legitimate effect on
>> subsequent tests.
> Well, the problem with the original commit was that any internal
> setting of CPPFLAGS/LDFLAGS within APU_FIND_EXPAT does not persist to
> build time as our build system does not utilize the end result of the
> values in CPPFLAGS/LDFLAGS.  As such, the --with-expat setting ended
> up being a no-op prior to this...  =(
> IMO, we shouldn't be leaving anything in CPPFLAGS/LDFLAGS and believe
> we're largely consistent on that point.  Most of our other "with"
> tests (LDAP, SSL, DBM, etc.) do a save/restore as we should not be
> depending upon the state of CPPFLAGS/LDFLAGS being valid.   We could
> remove all of the saving/restoring across the board, but I think it's
> better to treat each --with option as independent rather than being
> influenced by other options.  -- justin

IIRC, CPPFLAGS and LDFLAGS are save/restored because they are
user-defined environment variables that we don't want to override
(even though we have to temporarily add to them during a test).
It also helps isolate tests so that they don't side-effect each
other to death.


View raw message