7 ms·
I find autoconf to be good at its job - building a standalone script which runs micro tests - and still use it, but that automake and libtool add very little v
by marshallward 4y ago
I find autoconf to be good at its job - building a standalone script which runs micro tests - and still use it, but that automake and libtool add very little value for the reasons you described.
I do agree that m4 is rather unpleasant to write, and that the resulting tests are too slow (often because user defined macros do a poor job of cacheing) but I also think that these things could be addressed (newer macro languages, bundled or threaded micro-tests) while still preserving the good bits of autoconf.
- jonstewart 4y agoI once munged a configure.ac so that it would blast out its variables to a text file, i.e., CFLAGS="-g -O2" LDFLAG="-l openssl" I then replaced automake and libtool with tup, and the Tupfile would just source these variables from configure. It worked great! It's a pity that tup hasn't caught on.
- codys 4y agoThe lack of parallelization is also a pain point. When I needed something to test platform specific stuff and set defines/etc, I found that writing something to generate ninja & integrate the define generation (which ended up in some generated headers) into the total build process. This was very snappy. These days I use meson mostly, but I would love to see a complete build system really get into parallelizing platform checking and merge it into the normal build process.
- zajio1am 4y agoPretty much agree. In BIRD, we use autoconf, but not automake, instead we just use GNU make directly.