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.
--
Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
