Beyond Linux From Scratch is a collection of build recipes for people who want to build their own simple Linux distribution by compiling everything by hand. It is therefore a fairly representative collection of packages that are commonly used on a Linux desktop. I ran this list through shuf(1) and then picked out the first eight packages which a) use autotools and b) were not so outrageously hairy that I couldn't make sense of what was going on in configure.ac. These eight packages should therefore be excellently representative of what autodafe will have to deal with in the real world, minus a few upper outliers. I have ranked them in order of how difficult I predict it will be for autodafe to deal with them, from easiest to hardest.
This entire package is an overelaborate way of distributing a single static file and installing it in the right location. Autodafe's job should be trivial.
2. cpio
This configure.ac is pretty linear so your configurator approach should work in principle. However, you'll need at least a few new tests:
- Check for the presence of various helper binaries
- Check the return type of a function
- Check how to create a packed structure
There's also some odd custom M4 hackery for generating certain stubs. You'll have to figure out what's up with this and make sure you haven't broken MinGW.
Configurator logic will have to get more flexible to support what this configure.ac is doing. You need to build a list of warning flags whose initial content is conditional upon an --enable option, where the default value of that option depends upon whether this is a git checkeout or a release tarball. And then you need to test each of those flags to see if the compiler understands them, and remove unsupported ones.
Also, checking for xsltproc, and erroring upon failure, is conditional upon --enable-documentation being given.
4. openbox
Does trial compilations of particular X11 programs and modifies a bunch of different flag variables based on the results. Otherwise, nothing that looks hard, but there's a lot of it and therefore a good chance I've missed something.
The tricky thing about this one is that it'll break your assumption that getting a Makefile from a Makefile.in is just a matter of setting some variables at the top. The code coverage macro does more complex conditional generation of make recipes.
Nothing else in configure.ac looks particularly hard, but you'll need to add pkg-config support.
6. libseccomp
Has the same code coverage macro that xdg-dbus-proxy does. Needs to not only understand pkg-config but also generate a .pc file from a .pc.in using AC_SUBST. Interrogates what version of cython is installed by piping its output through sed.
7. gsl
This one's messy. There's a ton of stuff you can cut away because it's in POSIX now. But there's also a lot of testing for persnickety floating point behavior which requires compiling and running custom programs. This is a really bad design to begin with because it breaks cross-compilation.
8. asymptote
Replicating the logic of this project's configure.ac is clearly impractical without a similarly expressive scripting language.