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.
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
Zdaje się, że już wszyscy i ich babcie używają exploitu w xz/sshd, by szerzyć swoją agendę, więc i ja nie będę gorszy.
#Autotools to zły system budowania. Skryptu configure są absolutnie nieczytelne, więc nikogo nie powinno dziwić, że nikt nie zauważył złośliwego kodu — wszak nie różni się niczym od całej reszty tego bełkotu.
Statyczna konsolidacja i włączanie zależności są złe. Wiecie, dlaczego tak szybko udało się rozwiązać problem z liblzma? Bo wystarczyło cofnąć systemową bibliotekę do wcześniejszej wersji. Nie trzeba było przeszukiwać, łatać i wydawać na nowo setek projektów. Z #RustLang i Cargo nie byłoby tak łatwo.
Możecie winić #OpenSource za bycie niedofinansowanym i tym samym otwartym na tego rodzaju nadużycia w kluczowych projektach. Ale tak naprawdę żaden projekt IT nie jest w stanie być odpornym na poczynania złoczyńców o dostatecznych zasobach, a że przydarzyło się to xz, to tylko przypadek. Korpoprojekty też nie są bezpieczne, a tym bardziej własnościowe oprogramowanie z zamkniętym kodem źródłowym.
Tak więc: doceńcie Mesona, doceńcie dynamiczne ładowanie bibliotek, doceńcie dostawę oprogramowania przez dystrybucje, i rzućcie grosza wie… chciałem powiedzieć, devom open source.
@bagder#meson build has been amazing. I used cmake for a long time as it was "better than autotools" but meson is just light years ahead of everything else.
Here's something that the upcoming @pidgin 3 can do that Pidgin 2 could never hope to achieve:
building itself and all¹ of its dependencies (such as @GTK and @gstreamer) from source with MSVC, using the same build system as everywhere else, thanks to #Meson.
You can even run it without installing, using Meson's excellent devenv (though some icons are not found).
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).
#Meson needs to learn that Linux is not an operating system unto itself.
No really, like 95% checks for host_machine.system() == 'linux' are wrong, unless you really care about kernel specifics like Linux kernel modules. Typically what you want to check is:
is my compiler GCC / Clang? (use the Meson compiler object for that!)