Parallel ./configure
54 points by fanf
54 points by fanf
A while back I ventured into the guts of autoconf to see why no-one had yet pulled a trick like this with autoconf itself. The main difficulty is that autoconf uses a lot of fixed names for the temporary files in its test probes, so they stomp on each other if you try to run them in parallel. The choice of filenames is woven through the whole codebase so it requires a huge refactoring to fix. There are plenty of other issues, but that was enough to explain why it is so stubbornly serialized.
Yes indeed. I fear that this ship sailed along ago, and is probably one of the reasons people seem to switch to meson.
But I’d still welcome some/any improvement to autoconf, regardless.
I mean, meson doesn’t do configure tests in parallel either, AFAIK.
The real issue I have with autoconf is that the extreme emergent complexity is supposed to have the benefit that my code can be extremely portable. But in practice it still won’t be unless I can test on those esoteric platforms, and that’s both hard to do and less important these days when there are not a million UNIX variants in common use.
Personally I think one huge improvement that could made to autoconf-like systems is to get rid of M4 (and similarly weak string-only languages like CMake)
M4 is only necessary on the build machine – the target machine (the one that runs ./configure) only needs shell.
AFAICT there is no reason to use M4 anymore.
e.g. I picked this out from aclocal.m4. If you want to generate shell code, with a meta-function p(variable, command, modules),
Then you can easily express that in Python, or any other language (including shell itself, which would still be better than M4)
I guess M4 does have some iterative expansion semantics, but that is probably the reason that it is hard for everybody to read …
dnl _PKG_CONFIG([VARIABLE], [COMMAND], [MODULES])
dnl ---------------------------------------------
dnl Internal wrapper calling pkg-config via PKG_CONFIG and setting
dnl pkg_failed based on the result.
m4_define([_PKG_CONFIG],
[if test -n "$$1"; then
pkg_cv_[]$1="$$1"
elif test -n "$PKG_CONFIG"; then
PKG_CHECK_EXISTS([$3],
[pkg_cv_[]$1=`$PKG_CONFIG --[]$2 "$3" 2>/dev/null`
test "x$?" != "x0" && pkg_failed=yes ],
[pkg_failed=yes])
else
pkg_failed=untried
fi[]dnl
])dnl _PKG_CONFIG
Or you can just write the shell script by hand - https://github.com/oils-for-unix/oils/blob/master/configure
which QEMU does, and OCaml did at one point
i.e. Fabrice Bellard and Xavier Leroy don’t use GNU autotools :-P
The last line of the Makefile target runs rm ${FLAGS} ${FLAGS:%=%.log}. If this were removed, would this not mean that the results of the autoconf tests could be re-used between runs and only new tests would need to be run? Does make track the dependency on flags? This actually looks like a great use-case for shake to keep track of the out-of-band dependencies (flags/env).
I haven’t seen anyone comment on the data dependency in the example shown (second check relies on potentially changed CFLAGS). I wonder how much it matters