Re: make distcheck drops precious vars

[Ralf Corsepius]

Am Die, 2003-02-11 um 21.32 schrieb Alexandre Duret-Lutz:
> Hi Ralf & Raph,
> 
> [Raphael came across the same issue recently.]
> 
> >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
> 
>  Ralf> with automake-1.7.2, ""make distcheck" seems to drop
>  Ralf> autoconf's precious vars.
> 
> This is unfortunate, and I do sympathize.  However it's not
> clear that passing down precious variables is always the correct
> thing to do.
> 
> For instance some Autoconf macros update these variables (for
> instance adding flags such as -D, -I, -L, -l...), so we don't
> know, at make time, what the original user value was.  Passing
> the updated values seems troublesome.  Furthermore, some of
> these flags may have been added conditionally by --with/enable
> code, passing these down is undoubtedly wrong.
Yes, make distcheck drops --with/enable, too.

> I believe it's better if distcheck runs a "vanilla" configure.
Hmm, I would not subscribe to this. 

The "defaults" of a vanilla configuration are just an arbitrary set of
settings, and are not necessarily correct in an individual user's setup,
i.e. they are as bogus as are user provided settings.

> This helps testing a package in its default configuration,
> regardless of the developer's configuration.
Hmm, but .. if the default configuration does not work, and if user
assistance is required? 

I see a massive contradiction to the "usual answer" to the "include file
prerequisites -report to address@hidden" issue: "Use CPPFLAGS, ..."

IMO, this needs to be revisited.

> [...]
> 
>  Ralf> In my actual case, I need to set up CPPFLAGS to point to the include
>  Ralf> directory of a prerequisite package outside of the compiler's default
>  Ralf> search path. However, make distcheck drops CPPFLAGS :(
> 
> I know the feeling.  Fortunately there are a few workarounds:
> 
> 1) make DISTCHECK_CONFIGURE_FLAGS=CPPFLAGS=-I... distcheck
I'll give this a try ... but I am actually having doubts on it (Deep
source tree, Canadian Cross), we'll see if it works.

> 2) config.site
This is not an option to me. (Deep source-tree, Canadian Cross)

[I strongly believe in config.site not to be of any use except for
trivial cases (IMO, config.site is static table based configuration in
new clothes; c.f. imake in automake.info) ;)]

> 3) export CPPFLAGS
I thought, precious vars had been introduced to avoid using global
environment variables. 

IMO, this is the core of the problem and the key to a solution: Autoconf
changed to favor precious vars, but automake sticks with using global
vars. 

So if 3) from your list _really_ is a feasible solution, automake
probably should make the same move as autoconf did (I.e. to propagate
precious vars for "make distcheck")

Ralf