Well, as archaic as it is, and as awful as its execution model is, autoconf is at least somewhat useful: * determining availability of different syscalls (yay,

Well, as archaic as it is, and as awful as its execution model is, autoconf is at least somewhat useful: * determining availability of different syscalls (yay, printf) * determining compiler * verifying dependencies are installed and available (e.g., openssl) This last one is made much easier with pkg-config and the pkg-config macros in autoconf. There's an argument to be made that pkg-config is bad because it will fail the build if you're just missing the wrong .pc file somewhere, even if your system satisfies the needs of the program - true enough. But pkg-config _does_ make checking for dependencies in autoconf much easier, and it does something essential for correctness, which is gathering up the necessary compilation and linker flags of your dependencies to pass along to the compiler so that you can use them correctly and match ABIs. A good configure script will guide you through getting dependencies installed, which is much nicer for users than confronting them with compilation/linker errors.