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

> On 9/25/24 12:36 AM, Patrick Steinhardt wrote:
> > On Tue, Sep 24, 2024 at 09:59:52AM -0400, Eli Schwartz wrote:
> >> On 9/24/24 8:10 AM, Patrick Steinhardt wrote:
> >> Still I would prefer meson over autotools any day of the week. I'd also
> >> prefer autotools over cmake, mind you.
> > 
> > Is that a typo or do you really prefer autotools over CMake? :)
> 
> 
> 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.