#meson — Public Fediverse posts

https://www.europesays.com/es/549644/ así está el precio de salida en un céntrico espacio festivo #Business #Callejero #Economía #Economy #ES #España #Hostelería #meson #restaurante #Sanfermines #Spain

#wayland #hikari #stackingwm

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://codeberg.org/thomasadam/hikari

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

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

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

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.

One Open-source Project Daily

Code editor designed for elementary OS

https://github.com/elementary/code

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

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

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

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

Some fun facts about #Python limited API / stable ABI.

1. #CPython supports "limited API". When you use it, you get extensions that are compatible with the specified CPython version and versions newer than that. To indicate this compatibility, such extensions use `.abi3.so` suffix (or equivalent) rather than the usual `.cpython-313-x86_64-linux-gnu.so` or alike.

2. The actual support is split between CPython itself and #PEP517 build systems. For example, if you use #setuptools and specify `py_limited_api=` argument to the extension, setuptools will pass appropriate C compiler flags and swap extension suffix. There's a similar support in #meson, and probably other build systems.

3. Except that CPython freethreading builds don't support stable ABI right now, so building with "limited API" triggers an explicit error from the headers. Setuptools have opted for building explicit about this: it emits an error if you try to use `py_limited_api` on a freethreading interpreter. Meson currently just gives the compile error. This implies that package authors need to actively special-case freethreading builds and enable "limited API" conditionally.

4. A some future versions of CPython will support "limited API" in freethreading builds. I haven't been following the discussions closely, but I suspect that it will only be possible when you target that version or newer. So I guess people will need to be building two stable ABI wheels for a time — one targeting older Python versions, and one targeting newer versions plus freethreading. On top of that, all these projects will need to update their "no 'limited API' on freethreading" conditions.

5. And then there's #PyPy. PyPy does not feature a stable ABI, but it allows you to build extensions using "limited API". So setuptools and meson just detect that there is no `.abi3.so` on PyPy, and use regular suffix for the extensions built with "limited API".

#fvwm3 #autotools #meson #buildsystems

A little over six months ago, I said the following:

https://bsd.network/web/@thomasadam/113340194570527011

Since six months has passed, I've now pushed to `main` a PR which does just that -- removes autotools from #fvwm3 and replaces it with meson:

https://github.com/fvwmorg/fvwm3/pull/1191

So this has been your warning.

When I release fvwm3-1.1.3, it will be using meson only.

Any questions, please do let me know. I hope downstream packagers have made the transition. :)

@jloc0

Indeed.

Aside from all of the other work going on, there is also a concerted effort to migrate from using #autotools to #meson for builds.

#Xfce

🎄 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?

#HelPy #Helsinki #Finland #Python #meetup

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.

#Python

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.

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

Today's #experiment focused on using multiple layers for #webcam #capture. I believe it's always important to question #why an issue occurs and to have the willingness to #analyze it deeply and find a solution independently.

https://github.com/libsdl-org/SDL/issues/10698

#pipewire #v4l2
#ubuntu #fedora
#gcc #cmake #ninja #meson

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.

#ArchLinux #PackagerLife

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

#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 "$@"

EDIT: I do not mean to say that these new options should blanket-disabled globally. There however are currently some packages that have problems with GCC 14 (missing features or existing functions not being used, or just failing to build). Naturally these packages should be fixed themselves. Meanwhile -fpermissive will allow building most of these troublesome packages.

CLion 2024.1 Is Available! CMake Writing Assistance, Debugger Enhancements, and Improvements for Embedded Development
#Clang #CLion #News #Releases #20241 #Bazel #Cmake #Debug #Devicetree #Embedded #Meson

https://blog.jetbrains.com/clion/2024/04/clion-2024-1-available/

🔹#FluidSim our #CFD package also gets pre-compiled #Pythran extensions in wheels!

🔹#FluidImage the scalable #PIV package gets its first release in many years, also gets wheels! Heads up for another minor release soon, with breaking changes:

https://fluidimage.readthedocs.io/en/latest/changes.html#release-notes

🔹All this was made possible by the new #Meson support in #Transonic

https://transonic.readthedocs.io/en/latest/packaging.html

and a bit of CI/CD stuff powered by #cibuildwheel

#ThisMonthInFluiddyn

#ThisMonthInFluiddyn - Jan 2024 edition

Plenty on the packaging front this time.

🔹Ported to #pdm as packaging tool for most of our projects.

🔹Trying out #pixi as an alternative to #conda / #mamba. Lock files are great, but we had some hiccups.

https://foss.heptapod.net/fluiddyn/fluidsim/-/blob/cc2b4f9a644d41a224b1053c046f323591df809d/pixi.toml#L1-6

🔹#transonic has implemented an experimental support for #meson and #MesonPython. Unreleased and nothing final yet, but tests on #fluidsim and discussion at #Pythran is ongoing.

https://github.com/serge-sans-paille/pythran/issues/2170

#Python #fluiddyn

Developer: I don't think #meson or #cmake would be better at building all of this C/C++ than my custom #Python code.

Also developer: Writes 3500 lines of custom (and broken) Python code.

🤦

#ArchLinux #packagerlife

Today's progress on #FreeBSD #Linuxulator "userland from source" project: We have build systems! 🥳

Supported now (apart of plain #make): GNU #autotools (including #autoreconf), #cmake, #meson and #ninja!

They're all supported with their original #ports "USES", by some #bmake trickery in my new "USES=linuxsrc", fixing up just the parts that are different when building from/for the Linuxulator (like adjusting dependencies and commands to use the #Linux-native versions).

Ok, no #scons yet, didn't need it so far 🙈

You know how some people that know Java don't put it on their résumé because they don't want to work in Java?

For me, that's #autotools, #autoconf, #automake

PSA: please switch your projects to #Meson

Cross-compiling can be a great time saver when working with #GStreamer. Here's an example, using #Meson and gst-bulid, targeting a Arm64 CPU, in this case the #Xilinx high-performance #Zynq UltraScale+ MPSoC. http://col.la/2w7mk #OpenSource #Coding #Tech #HowTo