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

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

On 9 Jan, Andrey wrote:

> before starting to hack around configure we probably need to define the
> final goal. For module build some options are

The main goal I had in mind was just for the thing to actually compile
on my machine without messy fiddling.

> - module source location (in-tree vs. off-tree)
> - module detection (pre-configure, configure, post-configure)
> - module configuration (single configure possibly built from different
> sources vs. per-module configure)
> - build time (in-tree vs. off-tree)

I'd also add that a significant goal should be to keep the end result
as simple as possible because it could easily become very complex.

> Supporting them off-tree facilitates independent modules development but I
> have a feeling it is unlikely to be an issue in the near future :)

A lot more would have to be changed too allow off-tree modules so it is
probably best kept in-tree.

> Having separate per-module configure has one problem of passing results of
> main configure testing down because 2.5 disables caching by default. I could
> not find suitable solution to this problem unless recent autoconf has
> changed it. Besides to really utilize autoconf features list of
> sub-configure has to be statically included in top-level script. Advantage
> it has is that user can just drop in module source and does not need to
> worry about having suitable autoconf version

Can we have module-specific m4 fragments included into the main
configure script?

> Having module detection in configure (as is done currently) prevents adding
> per-module configure checks (at least, using autoconf language).

Why? Does it really matter if we have redundant configure checks?
Surely we need the result of some configure tests to determine which
modules to build anyway.

> So overall I am inclined to the build process that
> 
> - assumes all modules in-tree
> - builds initial modules list as part of preconfig and adds rule to Makefile
> to recheck and rebuild it later
> - (re-)builds configure from snippets optionally supplied by modules
> - provides --with-modules and --with-static-modules (with wildcard support)
> to control which modules are included and which are built statically into
> zsh, eliminating any auto-generated file editing.

Controlling what modules are linked with configure --with options would
probably be a lot nicer that the current file editing. Perhaps with
separate options, e.g. --with-module-pcre or --with-module-pcre=dynamic.

Oliver