The author's point is to do <em>without</em> a configure step entirely, not write your own.
A standard Makefile is perfectly capable of implementing these things in a manner which is clean, reasonably portable and without the level of indirection that makes things hard to debug.
My own experience is that autotools has evolved to feel less standard than the modern platforms it purports to smooth over the differences in; I seem to frequently find that I can't generate a 'configure' for a 3rd party software or libraries from Git repositories because I of the wrong autotools versions. Efforts to investigate this by unpicking the various macros etc. provided in the build have almost always been unsuccessful, leaving me building from distributed .tar.gz files. With something that feels like such a moving target after 30 years, I'm glad to see people realising the benefit of a simple Makefile that's easy to customise for the edge cases.
(*)(void*, const void*, const void*)
(*)(const void*, const void*, void*)
That's part of the argument: with standards compliant code, you don't need to do "what autotools does".
Well, you're responding to something that wasn't actually said; "these things" quotes specifically the list of requirements given by the previous poster -- CFLAGS etc.
Your example is indeed valid, it's an ugly case and I agree that testing for the feature specifically (rather than arch, compiler) is always preferred. But let's look at the practicalities -- how many of these cases do I actually need in a codebase to tip the balance that would justify use of autoconf? In your example, a simple #ifdef against the platform (Windows/BSD/Linux) and it's gone. qsort_r is off limits for massively portable program anyway, so autoconf's ability to help is limited anyway.
That's equivalent to the uname trick the GP was complaining about. That means your software won't compile in a lot of platforms.
On a small scale, I don't think that's a big problem. Somebody on those platforms only has to add the correct conditions to your #ifdef forest and if he sends the update back, other people on the same platform won't even have the same problem. It's not much different from software not working on untested platforms.
It starts becoming a problem when done often, or on high level (at the calling stack) code.
Is won't anyway; qsort_r has already limited me to a tiny number of platforms. If I care about further portability, autotools can't do anything to help me; my next step is not autotools, it's "don't use qsort_r"
> (*)(void*, const void*, const void*)
> (*)(const void*, const void*, void*)
Also, isn't the first supposed to be:
void*, size_t, size_t, int (*cmp)(const void*, const void*)
My SFINAE code was to handle a similar problem picking between a GNU-specific strerror_r and a POSIX strerror_r that have different signatures (both are available on Linux, determined by whether certain macros are set: https://linux.die.net/man/3/strerror_r , I couldn't just rely on those macros because I wanted my code to compile on any POSIX platform).
Both Linux and BSD chose to add a non-standard qsort_r(), each choosing different ways to do it.
OTOH, while I'm not a big fan of autotools internals (especially libtool), being able to run "./configure && make install" on tens of thousands of F/OSS packages is something I'd hate to loose. In fact, the extreme consistency in installation procedures (including use of pkg_conf etc.) and discipline in directory layout accross so many F/OSS packages is something I very much admire, given it's an unexpected outcome of a "Bazaar" style development model.
You forgot 'make'!
I'm tempted to turn this into a cheap shot about how the consistency obviously isn't worth much, but I won't.
./configure && make && sudo make install
./configure && sudo make install
I don't object that many projects have convulated and dated autotools scripts notably because they don't age well. It's easy to accumulate a lot of crap.
Most projects don't get autotools because they don't know how to use plain Makefile. They do because autotools bring much more than that.
So why not get a tool with 1/10 the complexity and 1/100 the legacy stuff of Autotool, but the same interface otherwise?
People who need the old checks 100% could continue to use Autotool-old, people who don't care for such BS could use the new.
Autotools is a huge pain in the ass for the dev, unfortunately I haven't found any alternative that didn't end up being an even bigger annoyance.
A decent, simple, easily customizable and portable C/C++ build system is still very much a unsolved problem as far as I'm concerned (and I've tried quite a few of them). At least autotools are supported basically everywhere.
By having autotools for the projects that need "everything" (legacy BS checks) and this leaner version for the projects that don't need them.
The same way there's vim and neovim without the legacy stuff.
CMake is faster than autotools and works fine with all the compilers talked about so far and all the windows compilers I know of.
Creating a CMakeLists.txt covering moderately complex build that links against a few libraries (but doesn't need and custom logic for moving files or other uncommon stuff) is normally just a few lines of code. Usually just one line of code per source file and per library (depending on how you feel about automatically including files this can be further shortened), then a little bit declaring the language and other settings. There are plenty of 10 line CMakeLists that can build large and seemingly complex projects.
As a rewrite using the same user interface but a completely different developer interface, there is mklove (https://github.com/edenhill/mklove). However, this just covers autoconf: you don't get the flexibility of automake. Also, I don't know how complete it is.
A rewrite just to speed up things a little is a bit useless. Autotools are not that slow. And if a rewrite was done, it would be a shame to keep the horrible syntax. What needs to be kept is
On the other hand, when something goes wrong with autotools, the first step is to pour yourself a drink.
I really feel a need for something like AC_TRUST_HOST or AC_TRUST_DISTRO or something like that would not check for each header or each function in some library. Instead it will check the version of GCC, libc, and compile some (hopefully just one) program and test.
Of course the common tests shall be skipped only in popular distributions. Say, Debian, Arch, Fedora (and their derivatives), to name a few.
On the other hand, using the autotools in a modern way is dead easy. You don't need to add many many tests if you don't intend to support old stuff. You get access to automake which is a fantastic tool on its own.
Don't read old tutorials, don't look at how big established projects are doing, look at the Autotools Mythbuster instead (autotools.io) and start with a minimal configure.ac.