Re: config.status refuses to run

[Ralf Corsepius]

On Tue, 2005-10-11 at 10:17 -0400, Sam Steingold wrote:
> Hi Ralf,
> thanks for your answer.
> alas, I still have questions:
> 
> > * Ralf Wildenhues <address@hidden> [2005-10-11 11:15:03 +0200]:
> >
> > * Sam Steingold wrote on Mon, Oct 10, 2005 at 06:34:10PM CEST:
> >> I am getting this:
> >> sh config.status --recheck
> >> ...
> >> configure: loading cache ../config.cache
> >> configure: error: `CFLAGS' was not set in the previous run
> >> configure: error: `CPPFLAGS' was not set in the previous run
> >> configure: error: changes in the environment can compromise the build
> >> configure: error: run `make distclean' and/or `rm ../config.cache' and 
> >> start over
> >> make[1]: *** [config.status] Error 1
> >> 
> >> I did not set any variables, not by hand.
> >> how do I avoid this error?
> >> 
> > *snip*
> >> 
> >> Unfortunately I am getting the above errors (`CFLAGS' was not set in the
> >> previous run &c).
> >> I understand why I am getting them, but I see no way to avoid them:
> >> if I configure module-dir1 before module-dir2, and module-dir2/configure
> >> changes CFLAGS, then module-dir1/configure will complain when I try to
> >> re-run it.
> >> So, how do you handle this issue?
> >
> > module-dir2/configure *should* *not* *change* CFLAGS.
> > It's a user variable.  Assume the user may need to override the developer.
> 
> how do I fix this:
> 
> AC_ARG_WITH([libtermcap-prefix],
> [  --with-libtermcap-prefix[=DIR]  search for ncurses and termcap in DIR],
> [case "$withval" in
>   (/*) CPPFLAGS="$CPPFLAGS "-I$withval/include
>        LDFLAGS="$LDFLAGS "-L$withval/lib
> esac])
>
> >> the only thing I could come up with so far is quite ugly:
> >> 
> >> --- module-dir/Makefile ---
> >> config.status : configure
> >>    sh config.status --recheck || (cd ..; rm -fv module-dir; make 
> >> module-dir)
> >> --- module-dir/Makefile ---
> >> 
> >> any other suggestions?
> >
> > 0) Fix module-dir2/configure not to change CFLAGS.
> 
> see above.
Just don't change them. E.g. try to use dedicated per (sub-)package variables 
such as 
TERMCAP_CPPFLAGS, TERMCAP_LDFLAGS instead and AC_SUBST them.

Or ... just don't try such magic as above and ask users to pass these
values through CPPFLAGS, etc. directly:

configure CPPFLAGS=-I/somewhere/include ...


> > 1) rm ../config.cache
> 
> ouch - I do not want to do this routinely, for every change in a
> configure file.
To be able to share caches, you must make sure these caches can be
shared.

> > 2) Do not share config.cache among all modules
> 
> too many tests are duplicates, this will increase re-build time
> enormously.
Unfortunately true. However, this is what most packages do, nowadays.
Also, practice tells that sharing caches rarely is worth the effort,
because the side-effects are hard to find.

Some packages with very expensive configure scripts resort to using
customized autoconf macros instead of using the default ones, or hack
around this issue (One package extensively doing so is GCC).

> > 3) Use a config.site file to "cache" some answers which are safe to cache.
> 
> all answers are safe to cache.
Normally, only very few options are safe to cache in a "config.site".

Ralf