For what it's worth, I agree that Autoconf tests for a lot of things that aren't necessarily relevant today. I don't think I need to worry about the existence of <stdint.h> on just about any platform.
But there ARE a lot of very relevant tests mixed in there too. These include things like:
- Width of an int
- Endianness
- Availability of arbitrary functions for linking
- Search through a list of libraries until one is found that provides a requested
function, then add that library to LDFLAGS
- Does the C compiler work?
- Do compiled binaries run on the build machine?
And it gives you control over things like:
- Mixing custom CFLAGS with conditional CFLAGS and package-specific CFLAGS.
- Enable/disable specific features at configure time.
- Add/change directories to search for existing headers/libraries needed for compilation
- Add/change directories for installation
Automake gives you:
- Automatic handling of platform-specific library creation differences.
Dynamic libraries in particular can have very different semantics across platforms, even living platforms today.
- Automatic handling of making parallel-safe Makefiles
- Standardized clean/test/install/dist/distcheck targets
- A reasonable unit-test system that's well integrated with the rest of Automake
If your software depends on this, you're doing it wrong.
As you said, depending on the existence of <stdint.h> is just fine, and you can then specify what you need. Even in the incredibly rare case of needing the width of int (serializing inputs and outputs of existing libraries interoperably on multiple machine ABIs) <limits.h> has you covered, albeit in an awkward way, unless you can assume POSIX and thus have WORD_BIT.
> - Endianness
If your software depends on this, you're doing it wrong.
If the wire/file format is little endian, input[0] | input[1] << 8, if stupid-endian, input[0] << 8 | input[1].
> - Search through a list of libraries until one is found that provides a requested function, then add that library to LDFLAGS
This is the exact opposite of what I want! If I'm depending on other libraries, I want that dependency explicitly listed and settable, not automagically found.
> - Does the C compiler work?
How is this reasonable to test? If it doesn't work, it can't actually do anything about it.
> - Do compiled binaries run on the build machine?
Totally ignores cross compilation, or deploys to other places -- e.g. containers.
> And it gives you control over things like:
These are generally useful, but the complexity required for autoconf is a huge cost to pay.
> Automake gives you:
All useful, yes. But these have never seemed to be particularly hard to do manually.
(Semi-) automatic handling of libraries, especially dynamic libraries, makes autotools worth the price, alone. Supporting one architecture manually is easy. Doing for six isn't. Doing it several dozen times, for all six, is spectacularly painful.
But there ARE a lot of very relevant tests mixed in there too. These include things like:
And it gives you control over things like: Automake gives you: