Re: make distcheck drops precious vars

[Alexandre Duret-Lutz]

>>> "Ralf" == Ralf Corsepius <address@hidden> writes:

[...]

 Ralf> Yes, make distcheck drops --with/enable, too.

It looks hard to know which of them should be passed to
distcheck, and which shouldn't.  Same for user-supplied
variables.

My feeling is that distcheck should perform a build in user
conditions.  That means it shouldn't use settings used by the
developer.  Developer can set various development-related
options when running ./configure; if they also need some options
as *users* they can set DISTCHECK_CONFIGURE_FLAGS at `make
distcheck' time.

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

 Ralf> The "defaults" of a vanilla configuration are just an arbitrary set of
 Ralf> settings, and are not necessarily correct in an individual user's setup,

Agreed.

 Ralf> i.e. they are as bogus as are user provided settings.

Still it's easier to pass extra arguments to a vanilla
configure than it is to *remove* erroneous arguments.

[...]

 >> 1) make DISTCHECK_CONFIGURE_FLAGS=CPPFLAGS=-I... distcheck
 Ralf> I'll give this a try ... but I am actually having doubts on it (Deep
 Ralf> source tree, Canadian Cross), we'll see if it works.

Hopefully sub-packages and cross compilation won't matter here.

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

Probably I shouldn't have suggested this anyway.

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

Although you can definitely use it this way (stuffing cache
results in it), it can also be seen as a convenient way to
record common CPPFLAGS (etc.) settings on a per-$prefix basis.
This can be useful in cross compilation setup too (a single
--prefix flag would set all cross compilation flags
automatically).

However, the only way to use this with distcheck (which uses its
own --prefix), seems to be through the CONFIG_SITE envvar.  That
doesn't seems terribly useful.

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

The documentation says precious variables are there to detect
varying *environment* between successive ./configure runs, for
the sake of cache consistency.

As I understand them, precious variables also allow to support
`CC=foo ./configure' better when it comes to `./config.status --recheck'.

I guess the documentation promotes `./configure FOO=bar' because
this will cause `./config.status --recheck' to retain *all*
argument variables, not only precious variables.

I confess this was not clear to me before I wrote it, so maybe I
got it wrong.

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

Precious variables really seem an internal ./configure machinery
to ensure cache consistency.

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

It just occured to me you could propagate all ./configure
arguments to distcheck using something similar to:

AC_SUBST([DISTCHECK_CONFIGURE_FLAGS], [$ac_configure_args])

I haven't tried.  I guess it does too much (especially when it
comes to arguments like --prefix).  I'd be glad to hear from
your experiences if you try this (or anything along this line).



By the bye, there is also needs for running distcheck several
times with different compilations options.  A project of mine
can use several third-party libraries as back-end.  If I let
distcheck do its job, it will pick the first library it finds.
I have to use a distcheck-hook to make sure the project can
build the in four different configurations.  (Jim used to do
that in former fetish releases, that's were I stole the code
from.)  I'd love have such a thing supported.
-- 
Alexandre Duret-Lutz