On Thu, 28 Jan 2021, Zack Weinberg wrote:
On Mon, Jan 25, 2021 at 5:42 PM Bob Friesenhahn
<bfriesen@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
