#meson — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #meson, aggregated by home.social.
-
Meet lambdock 🐑
Desktop Dock that is lightweight, hyper-hackable and combines GTK4/C performance with GNU Guile Scheme!• Wayland window tracking & popover HUDs
• Live socket REPL & hot-reloading
• Opt-in fisheye hover magnification
• Dynamic widgets (RAM, CPU, clock)
• Multi-dock & multi-monitor support
• Guix, Nix, openSUSE & Debian supportWorks on Sway, Hyprland, Niri, River, KDE & more.
🔗 https://codeberg.org/jjba23/lambdock
#Linux #Wayland #Guile #Scheme #GTK4 #Lisp #C #GTK #Meson #Guix #Niri
-
If there really is a #Meson god, forgive me, for I commit a cardinal sin every time I run my cursed cargo/meson builds
-
Current setup:
IDEs: #Gram Editor @krig Fantastic editor, Zed without the AI crap, more control on your extensions and LSPs.
CLion: The University where I teach makes you choose between Jetbrains or VisualStudio. Not touching MS products so CLion it is.
Current languages:
#Vala by @vala_lang
#Zig by @andrewrk
#python #c #cpp. I'm teaching stuff with these at the University.Build systems #meson #cmake and #zig depending on the project.
I've been enjoying this arrangement for a while 😄.
-
Today I learned about profile-guided optimization, the most obscure form of optimization I've heard of yet.
https://mesonbuild.com/howtox.html#use-profile-guided-optimization
-
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.
-
The installation process of the Java-GI application template (a small "example" GNOME app built in Java) is now completely driven by Meson.
Flatpak-builder calls meson, meson calls gradle, gradle produces a "fat jar" (with the shadow plugin). Meson installs the jar and everything else (icons, settings, translations).
Link to the application template: https://github.com/jwharm/java-gi-app-template
-
One Open-source Project Daily
Code editor designed for elementary OS
https://github.com/elementary/code
#1ospd #opensource #gtk #gtk3 #gtksourceview #hacktoberfest #meson #vala -
-
I think I'm going to be banned from using #Meson.
-
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.]
-
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.]
-
@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 😀 👍.
-
#meson рулит!
он говоритсамосравнение всегда дает true [-Wtautological-compare]
я смотрю вsage/crypto/sbox.pyxа там дляdef class SBox.__eq__на строке255написаноself._big_endian == self._big_endian -
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.
-
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.
-
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!
-
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 == ''`.
