#meson — Public Fediverse posts

Hey all,

I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.

What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2

The efforts of this can be seen on this branch:

https://thomas.gothub.org/repos/?action=summary&path=hikari.git

On the `ta/wlroots-0.19` branch (the default branch for now in this repo).

If you'd like to use #got, see:

This will be kept in sync with codeberg.

I think seems seem mostly working. Testing welcome though!

In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake

Any problems, file an issue on the repo, or speak to me directly.

Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.

#wayland #hikari #stackingwm #got #meson #bmake

Thomas Adam @[email protected] · 2026-03-08 · 23:08 UTC

Hey all,

I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.

What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2

The efforts of this can be seen on this branch:

https://thomas.gothub.org/repos/?action=summary&path=hikari.git

On the `ta/wlroots-0.19` branch (the default branch for now in this repo).

If you'd like to use #got, see:

This will be kept in sync with codeberg.

I think seems seem mostly working. Testing welcome though!

In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake

Any problems, file an issue on the repo, or speak to me directly.

Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.

#wayland #hikari #stackingwm #got #meson #bmake

Thomas Adam @[email protected] · 2026-03-08 · 23:08 UTC

Hey all,

I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.

What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2

The efforts of this can be seen on this branch:

https://thomas.gothub.org/repos/?action=summary&path=hikari.git

On the `ta/wlroots-0.19` branch (the default branch for now in this repo).

If you'd like to use #got, see:

This will be kept in sync with codeberg.

I think seems seem mostly working. Testing welcome though!

In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake

Any problems, file an issue on the repo, or speak to me directly.

Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.

#wayland #hikari #stackingwm #got #meson #bmake

Thomas Adam @[email protected] · 2026-03-08 · 23:08 UTC

Hey all,

I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.

What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2

The efforts of this can be seen on this branch:

https://thomas.gothub.org/repos/?action=summary&path=hikari.git

On the `ta/wlroots-0.19` branch (the default branch for now in this repo).

If you'd like to use #got, see:

This will be kept in sync with codeberg.

I think seems seem mostly working. Testing welcome though!

In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake

Any problems, file an issue on the repo, or speak to me directly.

Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.

#bmake #meson #got #stackingwm #hikari #wayland

Thomas Adam @[email protected] · 2026-03-08 · 23:08 UTC

Hey all,

I think I mentioned before about resurrecting the hikari wayland compositor (https://hikari.acmelabs.space) which seems not to be in active development.

What I've done is spent quite a bit of time upgrading hikari from wlroots-0.15 -> wlroots-0.19.2

The efforts of this can be seen on this branch:

https://thomas.gothub.org/repos/?action=summary&path=hikari.git

On the `ta/wlroots-0.19` branch (the default branch for now in this repo).

If you'd like to use #got, see:

This will be kept in sync with codeberg.

I think seems seem mostly working. Testing welcome though!

In addition to upgrading the wlroots version, I've also added the option to use #meson instead of #bmake

Any problems, file an issue on the repo, or speak to me directly.

Unofficially for now, I'm also lurking in the IRC #hikari channel on libera.chat, if that's more convenient.

#wayland #hikari #stackingwm #got #meson #bmake

Patrick :neocat_flag_bi: @[email protected] · 2025-12-18 · 03:00 UTC

One Open-source Project Daily

Code editor designed for elementary OS

https://github.com/elementary/code

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest #meson #vala

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest

Patrick :neocat_flag_bi: @[email protected] · 2025-12-18 · 03:00 UTC

One Open-source Project Daily

Code editor designed for elementary OS

https://github.com/elementary/code

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest #meson #vala

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest

Patrick :neocat_flag_bi: @[email protected] · 2025-12-18 · 03:00 UTC

One Open-source Project Daily

Code editor designed for elementary OS

https://github.com/elementary/code

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest #meson #vala

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest

Patrick :neocat_flag_bi: @[email protected] · 2025-12-18 · 03:00 UTC

One Open-source Project Daily

Code editor designed for elementary OS

https://github.com/elementary/code

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest #meson #vala

#vala #meson #hacktoberfest #gtksourceview #gtk3 #gtk

Patrick :neocat_flag_bi: @[email protected] · 2025-12-18 · 03:00 UTC

One Open-source Project Daily

Code editor designed for elementary OS

https://github.com/elementary/code

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest #meson #vala

#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest

Hylke Bons 🥜 @[email protected] · 2025-12-11 · 12:31 UTC

@tml so glad we have #meson now.

#meson

Jote 🏳️‍🌈 :verified_gay: @[email protected] · 2025-10-15 · 21:27 UTC

So I was sick today and needed to not do real work, so I resurrected an old tui based music player that I had not touched since 2010 (and it got it's start in 1997) .... and added some nice to have quality of life things, like better unicode support, sqlite databases instead of mmap files, etc....

I have tons of things to fix still.

https://github.com/itspluxstahre/glaciera

#coding #musicplayer #ncurses #c #meson #ninja

Jesus Michał "Le Sigh" 🏔 (he) @[email protected] · 2025-09-28 · 10:18 UTC

I think I'm going to be banned from using #Meson.

https://gitweb.gentoo.org/proj/blas-lapack-aux-wrapper.git/tree/meson.build?h=main&id=cd2c79792afc8e9de4e87eb344a28ea5fd46d868

#Gentoo

#meson #gentoo

Jezus Michał "Le Wzdych" (on) @[email protected] · 2025-09-26 · 10:10 UTC

1. Masz coś prostego do zrobienia. Wydaje się, że #Makefile będzie w sam raz.
2. W sumie warto zrobić to trochę bardziej przenośnie. Makefile będzie trochę bardziej skomplikowany.
3. Skończyłeś. Okazuje się, że jakaś durnowata wbudowana regułka w GNU Make wskakuje i dodaje `rm` na końcu, które kasuje część plików wyjściowych.
4. Użyj Mesona.

Zwykły dzień w #Gentoo.

[AKTUALIZACJA: Już żałuję użycia Mesona. Jak tylko masz do zrobienia cokolwiek, co nie jest w 100% dopasowanego do najbardziej standardowego szablonu, na każdym kroku dostajesz kłody pod nogi.]

#Meson

#makefile #gentoo #meson

Jesus Michał "Le Sigh" 🏔 (he) @[email protected] · 2025-09-26 · 10:08 UTC

1. Have a simple job to do. Figure out #Makefile will do the job.
2. Think a bit about portability. Makefile becomes slightly more complex.
3. You're finally done. It turns out that some stupid implicit rule in GNU Make fires and adds a `rm` at the end that removes part of the output.
4. Use #Meson.

Just an average #Gentoo day.

[UPDATE: Now I regret using Meson. If you do anything that's not 100% boilerplate, it just keeps throwing obstacles in your way.]

#makefile #meson #gentoo

sheerluck @[email protected] · 2025-09-18 · 13:23 UTC

#sagemath #gentoo #meson

https://github.com/cschwan/sage-on-gentoo/blob/master/metadata/news/2025-09-11-split-ebuild-to-disappear-sage-moves-to-meson/2025-09-11-split-ebuild-to-disappear-sage-moves-to-meson.txt

#sagemath #gentoo #meson

Michał Fita @[email protected] · 2025-08-27 · 18:15 UTC

@ygor #CMake can be good reason on its own to wish to switch to #cargo.

Update: in the past I cooked purely #C++ project built by cargo using `cc` crate. Worked like I charm until needed more changes and ended up with #Meson.

#cmake #cargo #c #meson

Glitchy Pixel @[email protected] · 2025-08-25 · 21:50 UTC

@vala_lang I can vouch for this project. Using Vala in #jetbrains #CLion (which has built-in #meson support) makes an amazing combo to develop on Vala and feel comfy about it with a modern toolset if you are into IDEs.

And also, CLion is free for open source projects, which is pretty likely you are, if you are using Vala.

If you are working on #vala, I recommend you check this out 😀 👍.

#jetbrains #clion #meson #vala

Dima Pasechnik 🇺🇦 🇳🇱 @[email protected] · 2025-08-21 · 19:23 UTC

python packaging is a nightmare, part $n+1$
#python #meson

https://github.com/mesonbuild/meson-python/pull/792

#meson #python

sheerluck @[email protected] · 2025-08-18 · 17:05 UTC

#meson рулит!
он говорит самосравнение всегда дает true [-Wtautological-compare]
я смотрю в sage/crypto/sbox.pyx а там для def class SBox.__eq__ на строке 255 написано self._big_endian == self._big_endian

#meson

sheerluck @[email protected] · 2025-08-18 · 13:56 UTC

Пытаясь собрать #sagemath от Volker Braun (это там, где уже удалили sage/pkgs/sagemath-standard так что emerge не может) через #meson, я узнал про пакет sci-libs/mkl

#sagemath #meson

Jezus Michał "Le Wzdych" (on) @[email protected] · 2025-08-18 · 09:05 UTC

Jeżeli piszecie bibliotekę, naprawdę powinniście unikać #CMake. To, w jaki sposób zaprojektowano ten system budowania sprawia, że wasz projekt staje się od niego zależny. Praktycznie uniemożliwia to przejście na inny system budowania w przyszłości bez sprawiania sporych kłopotów istniejącym użytkownikom. A jeżeli zdecyduje się wspierać wiele systemów budowania, to wówczas wasi użytkownicy będą blokować innych.

A wszystko przez to, że CMake używa niestandardowego systemu odkrywania zależności, który jest praktycznie niezgodny ze wszystkim innym, i tak złożony, że powtórna implementacja w innym systemie budowania jest szalenie skomplikowana. Więc kiedy inni zaczną polegać na tym, że wasza biblioteka instaluje pliki konfiguracji CMake (a jest to nieuniknione, bo po prostu tak się używa CMake), to wówczas nie będziecie mogli przestać ich instalować, nie psując ich projektów. A jeżeli będzie chcieli dalej je instalować przy pomocy innego systemu budowania, to powodzenia.

A jeżeli CMake to jedna z wielu opcji, które wspieracie, to niektórzy z waszych użytkowników zaczną przypadkowo zakładać, że mogą polegać na CMake. A na tym stracą wszyscy inni, którzy budują waszą bibliotekę przy pomocy innego systemu budowania, i nie będą mogli zbudować tego projektu, który zaczął polegać na CMake. A potem jest już tylko gorzej — coraz więcej dystrybucji jest zmuszonych do budowania waszej biblioteki przy pomocy CMake, i coraz więcej projektów polega na tym, że "wszyscy" używają CMake…

Używajcie systemu budowania #Meson — jest bardziej przejrzysty i lepiej przemyślany. A do wyszukiwania bibliotek używajcie plików pkg-configa; są proste i przenośne.

#WolneOprogramowanie

#cmake #meson #wolneoprogramowanie

Jesus Michał "Le Sigh" 🏔 (he) @[email protected] · 2025-08-18 · 08:42 UTC

If you're writing a library, you should really avoid #CMake. CMake is designed to lock you in. As in, once you release a #FreeSoftware project using CMake, you can't switch to another build system with causing real trouble to your users. And if you support multiple build systems, as soon as you start supporting CMake, some of your users are going to start locking everyone else in.

That's because CMake uses a custom package discovery mechanism that's hardly compatible with anything else, and that is so complex that it's very hard to reimplement it with any other build system. So when others start relying on the CMake config files being installed (and they naturally will, since that's how CMake does things), you can't stop installing them without actually breaking stuff. And if you want to preserve them without actually using CMake, well, good luck with that.

And if CMake is one of the options you support, then some of your consumers will accidentally start relying on it anyway. And this will be much worse for everyone, because now their projects won't work for people who build your project with any other build system. Which in turn will force more projects to use CMake anyway. Which in turn will make more people rely on CMake being used…

Use #Meson as the build system, it's clean and not designed to lock you in. Use pkg-config for library data; it's simple and portable.

#OpenSource

#cmake #freesoftware #meson #opensource

Thomas Adam @[email protected] · 2025-07-08 · 18:35 UTC

#xorg #x11 #wayland

So, I mentioned before about #12to11 which was an attempt at bringing #wayland to #x11

Well, here is #waylandx which is bringing this project something o a facelift:

https://github.com/ThomasAdam/waylandx

This is not a project which I was originally involved with though, all I am doing here is sprucing things up...

You should now be able to build this with #meson rather than #xmkmf tooling.

Next up, I need to address the version of the protocols its using, as they're a little out of date.

Given the recent noise about #wayback (https://lobste.rs/s/9vvhzr/two_weeks_wayback) this might be a nice alternative.

No matter how stupid it seems.

All #wayback does is run xwayland for you, which when all is said-and-done still won't mean much as you can't run wayland applications under it anyway.

Whereas, #waylandx strives to change that.

It might be intersting to see if you can run waylandx under xwayland.... heh, heh.

If you have any questions let me know. Better yet, open an issue on GH:

https://github.com/ThomasAdam/waylandx/issues

I've already put some there, if anyone is interested!

#xorg #x11 #wayland #waylandx #meson #xmkmf

Jezus Michał "Le Wzdych" (on) @[email protected] · 2025-07-08 · 07:11 UTC

Kiedy jesteś tak przyzwyczajony do tego, że języki programowania mają "wysokopoziomowe" metody sprawdzania, czy ciąg znaków jest pusty, że próbujesz na oślep znaleźć coś w stylu `not x`, `x.empty()`, `len(x) == 0`… i dopiero po chwili zastanowienia dociera do ciebie, że to może być po prostu `x == ''`.

#Meson

#meson

Jesus Michał "Le Sigh" 🏔 (he) @[email protected] · 2025-07-08 · 07:09 UTC

When you're so used to programming languages with high-level methods of checking for empty strings, that you grasp for something like `not x`, `x.empty()`, `len(x) == 0`… and only after a while of thinking, you realize that it's `x == ''`.

#Meson

#meson

Crow @[email protected] · 2025-06-19 · 23:52 UTC

About 10 days of round and round to install Motion 5 on my #rpi

hey where did you#libcamera go?

how to install libcamera to know if my camera is working before I try troubleshooting it in Motion?

How to install #meson to install libcamera?

How to install #ninja to install #meson

Why didn't I go with a regular dashcam? Oh right, no one BUILDS a privacy aware dashcam that will upload to MY server. AT ANY PRICE. #latestagecapitalism

#rpi #meson #ninja #latestagecapitalism

Jezus Michał "Le Wzdych" (on) @[email protected] · 2025-06-16 · 10:38 UTC

Ciekawostki o Pythonowym "limited API" i "stable ABI".

1. #CPython ma "limited API". Jak się tego używa, to kompilowane rozszerzenia są zgodne ze wskazaną wersją i wersjami nowszymi. Takie rozszerzenia dostają sufiks `.abi3.so` (albo podobny) zamiast np. `.cpython-313-x86_64-linux-gnu.so`.

2. Wsparcie podzielone jest między CPythona i systemy budowania #PEP517. Np. w #setuptools podaje się `py_limited_api=`, i wówczas przy budowaniu dodawane są odpowiednie flagi kompilatora i podmieniany jest sufiks rozszerzeń. #Meson ma coś podobnego.

3. Ale wersja "freethreading" aktualnie nie obsługuje "stable ABI", więc przy budowaniu z "limited API" dostaje się błąd kompilacji. Podobnie, setuptools rzuca błąd jeżeli z interpreterem freethreading podamy `py_limited_api`, a Meson po prostu pozwala się wysypać kompilacji. Tak więc autorzy paczek muszą sami sprawdzać, czy użyto kompilatora "freethreading", i wyłączyć wówczas "limited API".

4. Bliżej nieokreślona przyszła wersja CPythona naprawi to wsparcie. Nie przyglądałem się tematowi dokładnie, ale podejrzewam, że będzie to tylko możliwe, jeżeli będziemy budować rozszerzenia dla tej bądź nowszej wersji. Więc ludzie pewnie będą musieli budować dwie wersje — tę dla starszych CPythonów, i dla nowszych + "freethreading". No i oczywiście będzie trzeba odpowiednio zaktualizować warunkowe załączanie "limited API".

5. No i jest jeszcze #PyPy. PyPy nie ma "stable ABI", ale pozwala budować rozszerzenia z "limited API". Setuptools i Meson po prostu wykrywają, że interpreter nie obsługuje sufiksu `.abi3.so`, i buduje rozszerzenia z normalnym sufiksem.

#cpython #pep517 #setuptools #meson #pypy #python

Jezus Michał "Le Wzdych" (on) @[email protected] · 2025-06-16 · 10:38 UTC

Ciekawostki o Pythonowym "limited API" i "stable ABI".

1. #CPython ma "limited API". Jak się tego używa, to kompilowane rozszerzenia są zgodne ze wskazaną wersją i wersjami nowszymi. Takie rozszerzenia dostają sufiks `.abi3.so` (albo podobny) zamiast np. `.cpython-313-x86_64-linux-gnu.so`.

2. Wsparcie podzielone jest między CPythona i systemy budowania #PEP517. Np. w #setuptools podaje się `py_limited_api=`, i wówczas przy budowaniu dodawane są odpowiednie flagi kompilatora i podmieniany jest sufiks rozszerzeń. #Meson ma coś podobnego.

3. Ale wersja "freethreading" aktualnie nie obsługuje "stable ABI", więc przy budowaniu z "limited API" dostaje się błąd kompilacji. Podobnie, setuptools rzuca błąd jeżeli z interpreterem freethreading podamy `py_limited_api`, a Meson po prostu pozwala się wysypać kompilacji. Tak więc autorzy paczek muszą sami sprawdzać, czy użyto kompilatora "freethreading", i wyłączyć wówczas "limited API".

4. Bliżej nieokreślona przyszła wersja CPythona naprawi to wsparcie. Nie przyglądałem się tematowi dokładnie, ale podejrzewam, że będzie to tylko możliwe, jeżeli będziemy budować rozszerzenia dla tej bądź nowszej wersji. Więc ludzie pewnie będą musieli budować dwie wersje — tę dla starszych CPythonów, i dla nowszych + "freethreading". No i oczywiście będzie trzeba odpowiednio zaktualizować warunkowe załączanie "limited API".

5. No i jest jeszcze #PyPy. PyPy nie ma "stable ABI", ale pozwala budować rozszerzenia z "limited API". Setuptools i Meson po prostu wykrywają, że interpreter nie obsługuje sufiksu `.abi3.so`, i buduje rozszerzenia z normalnym sufiksem.

#cpython #pep517 #setuptools #meson #pypy #python

Jezus Michał "Le Wzdych" (on) @[email protected] · 2025-06-16 · 10:38 UTC

Ciekawostki o Pythonowym "limited API" i "stable ABI".

1. #CPython ma "limited API". Jak się tego używa, to kompilowane rozszerzenia są zgodne ze wskazaną wersją i wersjami nowszymi. Takie rozszerzenia dostają sufiks `.abi3.so` (albo podobny) zamiast np. `.cpython-313-x86_64-linux-gnu.so`.

2. Wsparcie podzielone jest między CPythona i systemy budowania #PEP517. Np. w #setuptools podaje się `py_limited_api=`, i wówczas przy budowaniu dodawane są odpowiednie flagi kompilatora i podmieniany jest sufiks rozszerzeń. #Meson ma coś podobnego.

3. Ale wersja "freethreading" aktualnie nie obsługuje "stable ABI", więc przy budowaniu z "limited API" dostaje się błąd kompilacji. Podobnie, setuptools rzuca błąd jeżeli z interpreterem freethreading podamy `py_limited_api`, a Meson po prostu pozwala się wysypać kompilacji. Tak więc autorzy paczek muszą sami sprawdzać, czy użyto kompilatora "freethreading", i wyłączyć wówczas "limited API".

4. Bliżej nieokreślona przyszła wersja CPythona naprawi to wsparcie. Nie przyglądałem się tematowi dokładnie, ale podejrzewam, że będzie to tylko możliwe, jeżeli będziemy budować rozszerzenia dla tej bądź nowszej wersji. Więc ludzie pewnie będą musieli budować dwie wersje — tę dla starszych CPythonów, i dla nowszych + "freethreading". No i oczywiście będzie trzeba odpowiednio zaktualizować warunkowe załączanie "limited API".

5. No i jest jeszcze #PyPy. PyPy nie ma "stable ABI", ale pozwala budować rozszerzenia z "limited API". Setuptools i Meson po prostu wykrywają, że interpreter nie obsługuje sufiksu `.abi3.so`, i buduje rozszerzenia z normalnym sufiksem.

#cpython #pep517 #setuptools #meson #pypy #python

Jezus Michał "Le Wzdych" (on) @[email protected] · 2025-06-16 · 10:38 UTC

Ciekawostki o Pythonowym "limited API" i "stable ABI".

1. #CPython ma "limited API". Jak się tego używa, to kompilowane rozszerzenia są zgodne ze wskazaną wersją i wersjami nowszymi. Takie rozszerzenia dostają sufiks `.abi3.so` (albo podobny) zamiast np. `.cpython-313-x86_64-linux-gnu.so`.

2. Wsparcie podzielone jest między CPythona i systemy budowania #PEP517. Np. w #setuptools podaje się `py_limited_api=`, i wówczas przy budowaniu dodawane są odpowiednie flagi kompilatora i podmieniany jest sufiks rozszerzeń. #Meson ma coś podobnego.

3. Ale wersja "freethreading" aktualnie nie obsługuje "stable ABI", więc przy budowaniu z "limited API" dostaje się błąd kompilacji. Podobnie, setuptools rzuca błąd jeżeli z interpreterem freethreading podamy `py_limited_api`, a Meson po prostu pozwala się wysypać kompilacji. Tak więc autorzy paczek muszą sami sprawdzać, czy użyto kompilatora "freethreading", i wyłączyć wówczas "limited API".

4. Bliżej nieokreślona przyszła wersja CPythona naprawi to wsparcie. Nie przyglądałem się tematowi dokładnie, ale podejrzewam, że będzie to tylko możliwe, jeżeli będziemy budować rozszerzenia dla tej bądź nowszej wersji. Więc ludzie pewnie będą musieli budować dwie wersje — tę dla starszych CPythonów, i dla nowszych + "freethreading". No i oczywiście będzie trzeba odpowiednio zaktualizować warunkowe załączanie "limited API".

5. No i jest jeszcze #PyPy. PyPy nie ma "stable ABI", ale pozwala budować rozszerzenia z "limited API". Setuptools i Meson po prostu wykrywają, że interpreter nie obsługuje sufiksu `.abi3.so`, i buduje rozszerzenia z normalnym sufiksem.

#python #pypy #meson #setuptools #pep517 #cpython

Jezus Michał "Le Wzdych" (on) @[email protected] · 2025-06-16 · 10:38 UTC

Ciekawostki o Pythonowym "limited API" i "stable ABI".

1. #CPython ma "limited API". Jak się tego używa, to kompilowane rozszerzenia są zgodne ze wskazaną wersją i wersjami nowszymi. Takie rozszerzenia dostają sufiks `.abi3.so` (albo podobny) zamiast np. `.cpython-313-x86_64-linux-gnu.so`.

2. Wsparcie podzielone jest między CPythona i systemy budowania #PEP517. Np. w #setuptools podaje się `py_limited_api=`, i wówczas przy budowaniu dodawane są odpowiednie flagi kompilatora i podmieniany jest sufiks rozszerzeń. #Meson ma coś podobnego.

3. Ale wersja "freethreading" aktualnie nie obsługuje "stable ABI", więc przy budowaniu z "limited API" dostaje się błąd kompilacji. Podobnie, setuptools rzuca błąd jeżeli z interpreterem freethreading podamy `py_limited_api`, a Meson po prostu pozwala się wysypać kompilacji. Tak więc autorzy paczek muszą sami sprawdzać, czy użyto kompilatora "freethreading", i wyłączyć wówczas "limited API".

4. Bliżej nieokreślona przyszła wersja CPythona naprawi to wsparcie. Nie przyglądałem się tematowi dokładnie, ale podejrzewam, że będzie to tylko możliwe, jeżeli będziemy budować rozszerzenia dla tej bądź nowszej wersji. Więc ludzie pewnie będą musieli budować dwie wersje — tę dla starszych CPythonów, i dla nowszych + "freethreading". No i oczywiście będzie trzeba odpowiednio zaktualizować warunkowe załączanie "limited API".

5. No i jest jeszcze #PyPy. PyPy nie ma "stable ABI", ale pozwala budować rozszerzenia z "limited API". Setuptools i Meson po prostu wykrywają, że interpreter nie obsługuje sufiksu `.abi3.so`, i buduje rozszerzenia z normalnym sufiksem.