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

I basically spent this afternoon trying to get started with a #cplusplus project with #Meson in #Windows .

Meson is apparently the only C++ build tool that doesn't make you completely insane over time (seems considerably more fun than, say, CMake). It's apparently very nice *if* you use the libraries that already have wrapdb files - it'll just download the stuff and use it automagically. If there's NO premade wrap, however, you get subjected to the full pain and fury of trying to compile shit with Visual C++ toolchain.

So that's where I decided to spend 4+ hours today.

I got a hello world app that did compile! But didn't print hello world. Or anything for that matter.

THEN I noticed that *all* of the libraries I need actually have #Python bindings, and can just be pulled in via pip.

So I'm going with Python. IF I need to rewrite this thing AGAIN in native-compiled language, I'll probably use Rust, because - surprise! - this stuff is crated.

#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/

Git 2.48 Released With Initial Support For The Meson Build System

#git #meson

https://www.phoronix.com/news/Git-2.48-Released?utm_medium=erik.in&utm_source=mastodon

New release for OpenYuusha! Mostly gruntwork... but LOOK MA, AN OPEN FILE WINDOW! And some pretty documentation for the underlying library...

https://gitlab.com/lenaing/open-yuusha/-/blob/main/CHANGELOG.md#010-alpha2---2024-12-07

Christmas is nearly here and that means it's time to join us for our December meet, hosted by #Nitor!

https://www.meetup.com/helpy-meetups/events/304793959/

Creating Python modules and libraries using #Rust, by Akseli Lukkarila

#Meson: a Build system in and for Python, by Jussi Pakkanen

#JAX: A Python ecosystem for machine learning and numerical computation, by Nazaal Ibrahim @nazaal

And did someone say something about a quiz?

I suppose I could use my experience to give some #PEP517 build system recommendations.

For pure #Python packages:

1. #flit_core (https://pypi.org/project/flit-core/) — it's lightweight and simple, and has no dependencies (in modern Python versions, for older Pythons it vendors tomli).

2. #hatchling (https://pypi.org/project/hatchling/) — it's popular and quite powerful, but has many vendored dependencies and no stand-alone test suite (which makes it painful to maintain in #Gentoo).

For Python packages with C extensions: #meson-python (https://pypi.org/project/meson-python/) — which combines the power and correctness of meson build system with good very Python integration.

For Python packages with Rust extensions: #maturin (https://pypi.org/project/maturin/) — which is simply a good builder for precisely that kind of packages.

Now, I strongly discourage:

A. #setuptools — lots of vendored NIH dependencies (that can alternatively be unvendored for cyclic deps), lots of deprecations over time (we're still seeing tons of deprecation warnings all over the place), many unsolved bugs (e.g. parallel C extension builds are broken in a few ways), a lot of technical debt, and if all that wasn't enough, it's slow.

B. #poetry-core — a very tricky build system with lots of pitfalls (I've reported a lot of mistakes done when migrating to it).

C. Practically any other build system — writing new backends is trivial, so everyone and their grandmother must have one. And then, they often carry a lot of NIH dependencies (if you're reinventing a build system, you may reinvent everything else), lack experience and reintroduce the same bugs. And if that wasn't enough, packaging them in distributions is a lot of work for no real benefit to anyone.

W sumie mogę dać parę rekomendacji systemów budowania #PEP517.

Dla paczek w samym Pythonie:

1. #flit_core (https://pypi.org/project/flit-core/) — leciutki, prosty, i nie ma zależności (za wyjątkiem włączonego tomli dla starszych wersji Pythona).

2. #hatchling (https://pypi.org/project/hatchling/) — popularny, duża funkcjonalność, ale ma sporo włączonych zależności, a testy są zależne od reszty projektu hatch (przez co w #Gentoo się mocno z tym męczymy).

Dla paczek z rozszerzeniami w C: #meson-python (https://pypi.org/project/meson-python/) — połączenie szerokiej funkcjonalności i poprawności mesona z dobrą integracją z Pythonem.

Dla paczek z rozserzeniami w Ruście: #maturin (https://pypi.org/project/maturin/) — po prostu dobry system budowania dla tego typu paczek.

Stanowczo odradzam:

A. #setuptools — mnóstwo włączonych do projektu zależności, które wynajdują koło na nowo (które można zastąpić zewnętrznymi, które z kolei mają cykliczną zależność od setuptools), ciągłe wycofywanie starej funkcjonalności (której wciąż używa mnóstwo paczek), wiele nierozwiązanych problemów (np. równoległe budowanie plików C jest częściowo popsute), sporo długu technicznego, a jeżeli to nie wystarcza, to do tego strasznie powolny.

B. #poetry-core — trudny do poprawnego użycia system budowania, w którym bardzo łatwo popełnić błąd (a zgłaszałem już wiele pomyłek, które ludzie robili migrując swoje projekty).

C. Praktycznie każdy inny system budowania — pisanie nowych backendów stało się banalne, więc każdy musi mieć swój. Do tego często mają mnóstwo zależności, które wynajdują koło na nowo (jak już ktoś chce wynaleźć własny system budowania, to może równie dobrze pójść na całość i wynaleźć wszystko), brak doświadczenia i tym samym powtarzają te same błędy przeszłości. A jeżeli tego nie wystarczy, to dodawanie pod nie paczek do dystrybucji to tylko kupa roboty bez żadnej realnej korzyści.

#fvwm3 #autotools #meson #muon #buildsystem

Hey all! Please note that although fvwm3-1.1.1 is close to being relesaed, there's still a few more things left to do.

Before that point, I'd like to take the opportunity to mention that as of fvwm3-1.1.1 fvwm3 is officially using meson/muon as the buildsystem of choice.

Autotools has been a tremendous help over the years. Heck, fvwm as a project started long before autotools existed.

But as technology changes, newer buildsystem alternatives have come along making better use of hardware, compilation speeds, etc.

Indeed, because of fvwm's age -- there's a tonne of custom m4 macros -- some of which are to work around issues long since gone. With autotools recently deprecating many of these, maintaining this was becoming difficult. Hence the change.

A six-month window exists once fvwm3-1.1.1 is released for downstream packagers to make the move from autotools to meson.

The `main` branch in the fvwm3 repository contains both buildsystems. Please give meson some testing!

A huge thanks goes to Kanjie (Matt Jolly) -- without whom none of this work would have been possible. Thanks, Matt!

For more specific details. please see: https://github.com/fvwmorg/fvwm3/discussions/1068

Questions? I'm here...

Już drugi tydzień, najnowsze wydanie #setuptools cierpi z powodu poważnego wyścigu. Jasne, to nie pierwszy tego typu problem w tej paczce, ale ten ma znaną przyczynę, z jasnym wyjaśnieniem, i powoduje regresję w wielu paczkach, które wcześniej działały.

A najbardziej absurdalne w tym jest to, że dla wielu ludzi wsparcie budowania rozszerzeń w C to jedyny powód użycia setuptools, i ta jedyna zaleta tego systemu budowania jest zepsuta na tak wiele sposobów. Pozostaje mi zasugerować użycie #meson, i jego backendu #PEP517, meson-python.

https://github.com/pypa/setuptools/issues/4653

For two weeks now, the latest #setuptools release has a major race condition bug. Sure, it's not the first race condition in C extension builds. However, this one has a known cause, with clear explanation why the change was wrong, and causes a regression for many packages that weren't affected before.

And perhaps the most absurd part is that many people are using setuptools only for their C extension building support, and that one feature that's keeping the project still relevant today keeps being broken in so many ways. At this point, I'm going to suggest using #meson and its #PEP517 backend, meson-python.

https://github.com/pypa/setuptools/issues/4653

oof... I'm also not excited to see that there is an effort for #meson to use cargo....

Cargo needs to get yeeted into the sun. Or just replaced entirely with a version that does nothing more than 'cargo vendor' and the world moves on to using an actual build system that doesn't require compiling binaries that print out compiler flags to stdout in order to actually work.

I hate cargo so much.

Not a strong vote of confidence for #meson when their tutorial can't be completed without an error that doesn't make any sense to someone unfamiliar with the tool:

subprojects/SDL2-2.30.6/meson.build:1306:6: ERROR: Tried to override dependency 'sdl2' which has already been resolved or overridden at /home/chipc/workspaces/slowgames/depot/mason/meson.build:4:

Some interesting features I wanted to try out but, I'm not sure I can maintain the motivation to overcome this.

Does anyone have an example they can point me to for bundling a CSS stylesheet with a GTK library that *isn’t* a full theme? Specifically this would be for styling a custom widget. I know how to package a stylesheet with an application, but I can’t seem to figure out how to make it work when developing a library.

today i learned #meson corrupts command line arguments because "what if you try to build your shit on windows". nevermind that i would like it to not corrupt backslashes on windows either. https://github.com/mesonbuild/meson/issues/1564

I created a small blog post. How to combine #meson and #PDM to build #Python extensions.
It's a good alternative to good old setup.py.

https://gaphor.org/2024/07/28/meson-python-pdm/

# Packaging #MesonPython