On Sat, Mar 30, 2024 at 06:56:27PM +0100, Kevin Kofler via devel wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > Meson outclasses CMake in functionality, > > LOL, how so? Everything in Meson is hardcoded, you have very little > flexibility (but still enough to plant a backdoor if that is what you want, > because you can just invoke a shell script or any other external command). > CMake is completely extensible with a complete programming language (it is > Turing-complete if and only if you use recursive functions; if you avoid > FUNCTION or at least recursive ones, then it is guaranteed to always > terminate and still usually expressive enough, but Turing-completeness > through recursion is there if you really need it). Pretty much every build system is Turing-complete, and pretty much every build system allows scripts to be called. Upstreams can do crazy stuff with any build system too. I think Meson hits the sweet spot where simple projects can be expressed in very few very readable lines. And common configuration tests that need to be done are still very readable. The handling of dependencies and options is very declarative. (Meson is also evolving, in early versions it was less so.) It'd be interesting to see some real statistics, e.g. over all Fedora packages, but in my experience, CMake projects tend to have many more files with lots of lines. > > clarity, and brevity. > > That is very much in the eye of the beholder, and it also depends on whether > you use modern CMake or legacy constructs that are often overly verbose. True ;) In _my_ eye, it's prettier. I guess we'll not achieve consensus. One particular issue I have with CMake as a downstream maintainer is it's often very hard to override linking or compilation options or when the project is using one of the cmake find scripts that gets something wrong… It's possible that those projects are "doing cmake wrong", but it seems that CMake makes it easy to do things wrong. > > I doesn't make sense to consider switching to CMake at this point. > > CMake being what the whole Qt and KDE community uses nowadays (even Qt > itself switched to it with Qt 6), it very much makes sense to switch to > CMake now more than ever. Right, but if one doesn't work on Qt, then this argument doesn't do much. [snip] > > One thing which is happening, mostly for unrelated reasons, it that > > systemd code is being changed to use dlopen() for various libraries which > > are usually not needed at runtime. The primary motivation for this is to > > omit such libraries from the initrd. But this also helps with overlinking. > > > > In systemd git main, libsystemd is only linked to libc, libcap, > > and libgcrypt + libgpg-error. A pull request to convert that that last > > pair to dlopen is under review. > > That helps somewhat (it would have prevented this backdoor from working), > but it also makes things even less transparent: How do we know whether some > random sd_foobarify() function or some random foobard linked against > libsystemd will (always or ever (and when?)) end up dlopening liblzma or > not? > > Distribution packagers tend to dislike dlopen due to the hidden dependencies > it introduces. This is true. It'd be great if the compilers and linkers supported a "weak dependency" model, where we'd use the normal call syntax and things would be the same as with a normal shared library link, but if that library is not found, the program would still load and run. Then we could still autogenerate those dependencies on optional libraries, but using Recommends instead of Requires. Right now the dependency handling needs to be handled manually, which is error-prone and annoying. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
