Strengths, weaknesses, opportunities, and threats facing the GNU Autotools

Re:Strengths, weaknesses, opportunities, and threats facing ... by marshallward on Sunday May 01, 2022 @10:16PM (#31230732)

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.

[ Parent | on HN ]

Re:Strengths, weaknesses, opportunities, and threats facing ... by codys on Sunday May 01, 2022 @11:35PM (#31231184)

The 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.

[ Parent | on HN ]

Re:Strengths, weaknesses, opportunities, and threats facing ... by jonstewart on Sunday May 01, 2022 @10:32PM (#31230836)

I 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.

[ Parent | on HN ]

Re:Strengths, weaknesses, opportunities, and threats facing ... by zajio1am on Monday May 02, 2022 @09:15AM (#31234721)

Pretty much agree. In BIRD, we use autoconf, but not automake, instead we just use GNU make directly.

[ Parent | on HN ]