It seems there are pretty big architectural questions to be answered. If you paid someone to produce something, you would get something, but would it be the right thing? There seems to be the necessity of preserving a linear configuration script like configure.ac for tests or other code that people want to write, along with providing a path for projects to transfer to a new parallel configuration system. One big question is whether you are going to think of your configuration step as: * linear script with a parallel part in it (i.e. call make from shell), or * a parallel system with a linear part in it (i.e. call shell from make) This has an implication for how existing configure.ac files can be parallelised. If it's the first idea, then you are going to put a macro somewhere in a configure.ac script that does the parallel bit. Otherwise, you are calling configure from somewhere within the Makefile. Either way results of checks have to be shared in one direction or another. The latter idea might be good as it would allow the configuration dependency graph to merge into the larger blob of the build system in general. Then there's the question of which bit of your configure script you replace first. If you think of the script as a directed graph of segments of code that have to run before each other, do you start by replacing: * segments which do not depend on many other segments: "near-initial" * segments upon which not many other segments depend: "near-final" (Maybe there are better terms than "near-initial" and "near-final".) If you replace near-initial segments, then you have to get information from make to shell. If you replace near-final segments, then you have to get information from shell to make. If you replace something in the middle, then you have to pass information both ways (tiresome). There seems to be an issue with extracting near-initial segments and doing them inside a parallel make system, and that is AC_REQUIRE. If segments that were AC_REQUIRE'd upon were done outside of the linear script, then it wouldn't be apparent that they'd been done, and they might be done twice. Replacing near-final elements seems better. The parallel part of the configuration could even run after AC_OUTPUT itself has run, to get the full results. This may not require any alteration to configure.ac files at all. Some "glue" would be needed to check that necessary information had been provided by AC_OUTPUT in its output files, and if not running the tests from within the parallel configuration system (configure.ac might not even exist and everything would have to be done there). It seems reasonable that after the configure.ac script has run, a few more tests could be done and the results added to the configuration.
