I'd argue that for Qt this approach makes sense because they provide a well defined API that they stick too. The developer can also ask for specific component if it just want them (like QT GUI, QT SVG...).
I agree that this is more problematic with less common, more buggy libs where the API keep changing, but in this case it's quite easy to check for specific files, specific functions, ...
All this assumptions have huge consequences in terms of velocity and ease of use.
For your second example, this does not test for the compiler but for the provider of the SSL library.
Clang does not provided it, so it's not a problem.
But I get your point.
My counter-argument is that more flexibility is left to the developer to assume stuff. These assumptions make things easier in most cases. In corner cases, then you need to provide explicit values to the module so he can find what you need.
I didn't really mean a literal database. I meant stuff like this:
https://github.com/Kitware/CMake/blob/master/Modules/FindQt4...
This is pretty typical CMake. It's encoding that for a particular version of Qt, add a few more compilation flags. It's a "knowledge base" of Qt versions encoded as a CMake module.
The autoconf way would be to try to link a minimal program to Qt, and if it fails, try to see if adding more libraries makes the linking succeed.
Or this, for example:
https://github.com/Kitware/CMake/blob/master/Modules/FindOpe...
It is trying to account for two popular compilers on Windows but not with Cygwin. It's the whole chain of "if Windows, if cygwin, if mingw, if msvc" what I called a "database" above.
Doesn't clang work on Windows these days? What will this knowledge base do now? Shouldn't clang work almost like mingw? But because it misses the "if mingw" branch, code that probably would have worked for clang will be skipped over.