Re: Parallel configure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [GCC Help]     [Kernel Discussion]     [RPM Discussion]     [Red Hat Development]     [Yosemite News]     [Linux USB]     [Samba]

  Powered by Linux