Re: parallelized configure

[Bob Friesenhahn]

On Tue, 14 Jan 2014, Mike Frysinger wrote:
> there's semi-precedence though with introducing new macros when there's no
> confidence in safely converting existing one.  consider:
>         AC_CHECK_FUNC beget
>         AC_CHECK_FUNCs beget
>         AC_CHECK_FUNCS_ONCE
> same for HEADERS and DECLS.  maybe time to beget a
> AC_CHECK_FUNCS_ONCE_PARALLEL ? :)  or maybe enshrine the ONCE behavior and
> call it AC_CHECK_FUNCS_PARA.  that'd cover a decent amount of ground (albeit,
> not as much as would truly be possible from an interlocked pipeline) without
> too much pain.

Unfortunately, that is only part of the problem.  The main problem is 
the cascading shell variable definitions which appear, are modified, 
or even disappear as configure script statements are executed.  Some 
of these variable modifications are done as actions of the macros and 
others are done by code added by the package developer.

Configure could be sped up by using a shared caching system for common 
tests (e.g. standard header file existence) or perhaps even by 
creating a new shell which is a closer fit to what configure needs.

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/