GIMP 3.0’s development has improved significantly because the development team has switched from autotools to Meson for compiling. This has resulted in a major speed-up when building GIMP, allowing for quicker testing and development.

https://mesonbuild.com/

I love documentation like this. Straight to the point.

Was nimmt man eigentlich heutzutage für kleinere C-Projekte als Build-System, wenn man von frickeligen #Makefiles weg will? #CMake? #Meson? #coding, #c

#Git 2.48 is out[1].

#GitHub has a blog post with a few highlights:

https://github.blog/open-source/git/highlights-from-git-2-48/

* Faster SHA-1s without compromising security

* Bringing --remerge-diff to range-diff

* Memory leak-free tests in Git

* Introducing #Meson into Git

* now-deprecated features are now listed in Documentation/BreakingChanges.txt

* if the remote has a default branch but refs/remotes/origin/HEAD is missing locally, then a fetch will update it.

[1] https://lore.kernel.org/all/xmqqplku7cvm.fsf@gitster.g/

The git 2.48 release introduces support for building #git with #meson.

Originally added with this commit:
https://git.kernel.org/pub/scm/git/git.git/commit/?id=904339edbd80ec5676616af6e072b41804c1c8eb

Note that the existing build system using autoconf and make was not removed. I guess they will monitor the adoption in CI, but I expect they will eventually fully switch.

Mumbles something about some kernel projects suddenly becoming not reproducible, using broken #makefile based setups, also offering #meson, but that being broken (and leading to differing output!!), too.

I'm quite tired of these types of untested projects, without any CI. Maintainers pointing contributors to their 10 step "easy to follow" mail based workflow isn't helping either I guess

I have less and less energy packaging stuff like that.

Crazy, how difficult it is coerce modern build systems to build both library types for the project (shared and static) and yet link the executable with the static one preferred. The amount of black magic and jumping through hoops one needs to attempt is quite staggering. #linux #cmake #meson #autotools

My expectation: #Rust will replace most other low level languages for relatively low level use cases. For example platform libraries, kernels, OS components, like services etc.
But I also think that a lot of these projects (especially platform libraries) care about that they won't just be able to be used by other Rust code.
Also my expectation: For a lot of these projects, #Meson will replace #cargo, because it just supports more features, and makes integration into an existing system easier.

Are there any useful learning resources out there that are essentially "build systems for dummies"?

I haven't built any complex projects from source manually so far (spoiled by meson + GNOME Builder's Flatpak integration), but I'm finding myself wanting a better understanding of what's actually happening under the hood to turn the stuff in my project folder into something runnable. I don't know much about tweaking meson.build files, for instance.

#GCC14 promoted some warnings to errors. This can break #autoconf, #CMake, #Meson or other build environments autoprobing for features, resulting in code built with missing or altered functionality. This could even lead to security impact, if some security related feature is unexpectedly not enabled.

Passing CC as "gcc -fpermissive" should fix this. If this is not an option there's even the nuclear option of adding a gcc wrapper script that does:

#!/bin/sh
exec /usr/bin/gcc -fpermissive "$@"

Hot take after an afternoon un-fsck-ing a #CMake project: `*Config.cmake` files are so much harder to debug than `*.pc` #PKGConfig files, so not only are you trying to make sense of a Turing complete project definition but all the transitive dependencies that happen to use CMake too

I'm increasingly a #meson fan.

So I'm trying to get mod_gnutls build with #Meson. For testing an HTTPS server I need a PKI. With Autotools I have a Makefile with pattern rules to generate private keys, generate certificates from private keys, templates, and CA certificates (also generated by Make, except the root CA is self-signed instead). An then I list all the certificate & key files as check_DATA so they get built before running tests.

How would I go about building those in Meson? I'd rather avoid having to write a custom_target for each and every one of those files, there are too many. ​​

I suppose everyone and their grandmother is now using the xz/sshd exploit to further their own agenda, so I am going to take this opportunity to further mine as well.

1. #Autotools are a bad build system. If configure scripts are completely unreadable, there should be no surprise that people won't notice obfuscated malicious code in there, provided that everything else is obfuscated by design.

2. Static linking and vendoring is bad. Do you know why the prompt #security response was possible? Because we just had to revert to older liblzma. We didn't have to check, patch and re-release hundreds of projects. It wouldn't be this easy with #RustLang and cargo.

3. You can blame #OpenSource for being underfunded and open to abuse in core system packages. However, no IT project can be resilient to a sufficiently powerful bad actor, and that it happened to xz is just an incident. Corporate projects aren't resilient to it, neither is proprietary, closed-source software.

So, embrace #Meson, embrace dynamic linking, embrace distribution packaging and donate to open source developers.

Man, #meson is pretty good. Fast, separate build directory, OK config language…