Re: Parallel configure

[Bob Friesenhahn]

On Thu, 28 Jan 2021, Zack Weinberg wrote:
> On Mon, Jan 25, 2021 at 5:42 PM Bob Friesenhahn
> <bfriesen@simple.dallas.tx.us> wrote:
> > The challenge here is that a considerable part of configure scripts
> > depend on decisions which were made before.  There is no dependency
> > information currently in configure scripts.
>
> Yes, but it may not be as bad as you think.  The "check a list of
> these things" macros (e.g. AC_CHECK_FUNCS) could be internally
> parallelized right now.  Many of the core macros depend only on the
> things that they AC_REQUIRE, and produce information that is _usually_
> consumed only by AC_OUTPUT.  And we know of any macro whose internal
> structure is in the preferred form

I am glad that you mention AC_CHECK_FUNCS since this is actually 
something which does definitely have dependencies.  The reason for 
this is that AC_CHECK_FUNCS uses the already built LIBS while it 
performs the tests.  When library dependencies are not working (which 
they would not be for a static build or for targets which do not have 
this notion) then it is necessary for either LIBS to already be built 
up with good stuff, or that the AC_CHECK_FUNCS guesses the list of 
additional libraries which may be needed (that can be very difficult 
to do).

While I am not sure that the GraphicsMagick configure script is a good 
example of how to write a configure script, it does provide an example 
of how LIBS gets built up incrementally using already passed tests, 
working in a least dependent to most dependent manner.  The answers it 
arrives at might not be strictly correct but it does work.

Besides parallelism, another way that configure might run faster is by 
supporting methods commonly used for bisection.  This would be a 
totally different way for configure to work.  However, the result 
might not look like "feature based" testing.  Instead it would be 
"this is the set of options which allowed the test case to fully 
compile".  The test case may then depend on several features at once 
and could in fact be everything needed for a given translation unit to 
compile.

I have been astonished at how fast Mercurial's 'hg bisect' managed to 
isolate the changeset which introduced a problem.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt