On Wed, Sep 25, 2024 at 02:02:34AM -0400, Eli Schwartz wrote: > 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. All of this is very valuable data to make my case for Meson instead of CMake. Appreciated, thanks! Patrick
