RE: autoconf 2.5 (Re: PATCH: terminfo horor)

[Borzenkov Andrey <Andrey.Borzenkov@xxxxxxxxxxx>]

> >
> > The configure script is creating config.modules twice. Second time
> > round when evaluating $link using the code in terminfo.mdd,
> > $ac_cv_func_tigetstr was unset. It seems the configure script runs
> > config.status. By running configure with --no-create, it was happy to
> > build terminfo.so. Switching from autoconf 2.57 to 2.13 also solved the
> > issue.
> >
> 
> looking in current zshconfig.ac it should not do it unless something else
> is
> buggy.
> 
> > configure cats config.modules.sh into config.status using
> > AC_OUTPUT_COMMANDS which is obsolete in autoconf 2.5. Using the new
> > AC_CONFIG_COMMANDS doesn't help because variables like
> > $ac_cv_func_tigetstr are still not set.
> >
> > Does anyone understand the real point of config.status? Why does
> > configure need to run it? I get the impression that it should contain
> > just a duplicate of what is in config.modules as created and recreate
> > it as opposed to rerunning scripts to derive its contents.
> >
> 
> I do not remember if it was me who put it in. Anyway
> 

it was Bart in 17659,17661; if config.modules.sh is really called twice it
means we have 2.5 that does define those variables it is not supposed to.

The problem is cache variables are not defined in config.status nor is
config.cache garanteed to exist (2.5 does not cache by default). Meaning we
cannot rely on them and have to add some status variable that is set by
configure.

What I intended was to allow modules to supply "configure plugins" to make
whatever checks are needed; then configure could simply emit list modules to
build without generating (mostly identical) makefile fragments for every
module. Hmm ... it does look suspiciously similar to linux kernel, does not
it? :)

But it is near to impossible to create such plugins as shell scripts
(autoconf simply does not support it).

What is possible is to provide configure snippets and make Util/preconfig to
generate modules.m4 that includes them' modules.m4 would then be included by
zshconfig.ac. Unfortunately it is not easy to handle dependencies (i.e.
module added or removed after modules.m4 has been created). 

-andrey

> - autoconf 2.13 creates output files as the final step in running
> configure.
> It is using environment variables CONFIG_FILES et al to pass information
> which files are to be created further down
> 
> - autoconf 2.5 does not create anything in configure. Instead the sole
> point
> of configure script is to create config.status - and it is config.status
> that finally does (should do) the job of creating files, making
> substitutions etc
> 
> apparently zshconfig.ac  tries to detect 2.5 by checking if
> $CONFIG_FILES$CONFIG_HEADERS is empty; if it is it dumps config.modules.sh
> into config.status. Hmm ... and runs it once more after that ... that
> looks
> strange.
> 
> > We really ought to ditch support for autoconf 2.13 in the 4.1 branch.
> > Not having a mixture will just make things simpler.
> >
> 
> yes. 2.5 makes many things simpler and more consistent. OTOH I remember I
> have tried to switch over to 2.5 way - doing job in config.status - and
> failed for some reasons (do not remember exactly) - I guess I attempted to
> move creation of all makefiles into config.status instead of creating
> makefiles during make run. Also it definitely was not portable across
> 2.13/2.5
> 
> we could try it once more if 2.13 compatibility is not an issue.
> 
> -andrey