Barnes: Parallel ./configure

Also, with many platforms and (non-)standards having fallen out of fashion in the last two decades, a lot of tests are also more or less obsolete in the sense that one's configure.ac need not invoke them any more, like

$CC not supporting -o
ANSI C prototype support
Support for keywords "inline", "volatile", "const"
AC_SYS_LARGEFILE (just unconditionally -D_LARGEFILE_SOURCE?)

It was better than nothing, but still slow.
https://github.com/knneth/mlnx-ofa_kernel/tree/e9390164da...
See config/parallel-build.m4

And it's ugly. And still slow. Just not as slow as running all of them sequentially.

pkg-config is for a specific purpose: it's for linking to a dependency with a cooperative maintainer (they must provide .pc metadata describing their library), and is most useful if the dependency meets several assumptions:

* it's usually a C or C++ library (although pkg-config can also be used to check for "data" packages like wayland-protocols)
* there is only one implementation of the API, or maybe a small finite number (for example IJG libjpeg and libjpeg-turbo; but if each proprietary Unix had its own unique implementation then pkg-config is probably the wrong tool)
* the API/ABI is sufficiently carefully-managed that 99% of the time the only compile-time functionality checks you need are of the form "do we have version 1.2.3 or better?"
* the .pc file is correctly-written and describes all the dependencies

It's a replacement for every library having its own special "detect me" script like sdl2-config, or its own special Autoconf macro like AM_PATH_GLIB_2_0, or both, which scales poorly - especially when those scripts and macros tend to work in simple cases, but not work in more complex situations like cross-compiling. It is not a replacement for Autoconf checks in their full generality.

For libraries that meet those assumptions (for example libjpeg, libpng, GTK, SDL, Qt), yes it will make it much, much easier for distro packagers if you check for the library with pkg-config instead of open-coding your own dependency detection. It'll probably make your dependency detection easier and more reliable for you, too. It's also good for users who are installing your software in unusual environments with dependencies installed in non-standard places (it gives them a non-library-specific way they can override the automatic detection and force a particular result), or users or packagers who are cross-compiling.

pkg-config is not for detecting whether your software is being compiled on a platform where libc does or doesn't have a frobnicate() function, or whether the compiler supports the -Wno-complaining option, or whether C++17 is available. That's outside its scope. Those checks are likely to be the ones with biggest impact on how long it takes to run ./configure, just because if they are checked at all, they tend to be rather numerous (each one is small and quick, but the time taken adds up), so using pkg-config will not necessarily speed up a configure script significantly: the reasons to use it are non-speed-related.

pkg-config also isn't for detecting libraries that aren't cooperating with the pkg-config ecosystem: if the dependency library has no .pc file at all, or a .pc file that is well-intentioned but wrong, then pkg-config will not help you to detect it (but adding or fixing the .pc file so that the dependency can be detected more easily might be a valid feature request or bug report).

Yes, this! At a libc API level, actively-maintained POSIXy operating systems are more similar than they are different, and the fastest possible configure check is the one you don't do.

The first portability decision to make in a project is whether it aims to be POSIX-only, or whether it aims to be portable to Windows. POSIX and Windows are sufficiently different "shapes" that if both are supported, in practice there are going to be two code paths anyway; and it's likely that it will be easier to test "#ifdef _WIN32" or ask the build system "is this Windows?" rather than inventing configure checks that end up meaning the same thing.

For the POSIX code path, if you choose a baseline level of functionality and say that you require it, a lot of configure checks become unnecessary: there's no point in checking for "normal POSIX things" unless someone has gone to the effort of testing a code path for specific platforms where they're missing (and it's 2025, so 1980s proprietary Unix is probably out of scope for most projects now). Similarly if you can nominate some reasonable C standard like C99 or C11 and say "your compiler must be at least this modern", or the equivalent for C++, then there's no need to feature-test for individual functions from that standard.

Similarly, for the Windows code path if you have one, if you choose baseline Windows/SDK/compiler versions and assume them, then configure checks for anything provided by that baseline are just a waste of time.

Depending what the project does and how much OS integration it needs, some projects will also need a special code path for the macOS/iOS/etc. family, or for Android, or something like that. Again those are easily detected at the preprocessor or build system level.

*Then*, after distinguishing between those major code paths, it becomes useful to do feature-tests for whether particular corners of functionality are available or not - but every time there's a feature-test for whether there is a frobnicate() function, it should be because the project's source code is genuinely looking at whether HAVE_FROBNICATE is defined, and doing things differently in the case where it is, and the case where it isn't.