Re: ./configure fails to link test program due to missing dependencies

On 9/25/24 12:36 AM, Patrick Steinhardt wrote:

POSIX sh (used by autotools) has a more powerful and capable type system than CMakeLists.txt (this is not a typo either! compare CMake's "semicolon;delimited;string" type to POSIX sh's "$@" type)

m4 is less painful to debug than successfully configuring, spending 4 hours compiling a ginormous project, then failing at the end with (this is because of the type system again, since there is no type for dependency-was-not-found they smuggle it along as a string value with special meaning): ld: cannot find -lCURL-NOTFOUND: No such file or directory

If you enable cmake's test system, but you do it inside a subdir e.g. inside tests/CMakeLists.txt, you cannot run "ctest" (or make test) except inside that subdir. ctest will exit 0, and no rules will be generated to descend into the correct directory instead. This has bitten me a *bunch* of times in Gentoo packaging and it always throws me for a loop. I don't understand the point of such a design.

I have never had autotools refuse point-blank to detect that another package is installed and usable for ***shared linkage*** because my distro automatically removes static libraries when a corresponding shared library exists, and

CMake Error at /usr/lib64/cmake/libssh2/Libssh2Config.cmake:92 (message):
  The imported target "Libssh2::libssh2_static" references the file

     "/usr/lib64/libssh2.a"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

     "/usr/lib64/cmake/libssh2/Libssh2Config-relwithdebinfo.cmake"

  but not all the files it references.

autotools projects have never harmed me by running the square of my make -j$(nproc) count due to recursively running cmake inside of generated Makefiles -- perhaps that isn't strictly the fault of CMake but cmake does very little to discourage it: https://bugs.gentoo.org/921309

autotools doesn't have much in the way of built-in tooling for detecting "packages" instead of "libraries" for arbitrary system dependencies. It allows you to use pkg-config or code your own (foo-config scripts were popular once and in some circles still are). You might think this is a negative, but it's actually a positive compared to cmake, which includes builtin dependency finders for e.g. zlib that break on a simple version update because they locate the header file, open it up and use regular expressions to extract a #define for the package version instead of asking the preprocessor... a very brittle regex, too: https://gitlab.kitware.com/cmake/cmake/-/issues/25200

autotools projects don't automatically detect your end-to-end integration test's dummy project, integrate its results into your build, and install some of your project files twice, once with bad values, but only when you run the project tests (this one was very fun): https://github.com/nlohmann/json/issues/2907#issuecomment-890580081

...

I'm probably biased, but some of these failure modes are *weird*. And they basically never require the CMakeLists.txt to do something considered non-idiomatic in order to trigger the issue.