One of the sad side-effects of the #xz #backdoor is that many projects feel like they need to move away from #autoconf, when the problem wasn’t autoconf itself, but shipping a bunch of .m4 files – and that nobody diffed repo vs tarball (if nobody does that, it doesn’t matter what you do in the repo, e.g. switching build systems).
This is sad because it means cross-compiling stuff will soon no longer be possible, as autoconf is so far the only thing that gets cross-compiling right. CMake is a complete mess, Meson is far from great for cross-compiling and everything else just outright doesn’t support it.
People, clean up your configure.ac, get rid of .m4 and audit repo vs. tarball! That’s less work, much more effective and doesn’t kill cross-compiling!
Also, if you absolutely must blame a piece of software that was used by xz for this: That’ll be #gettext, which was the reason for the insane amount of .m4 files in the first place. gettext is a mess and that is really something we should get rid of.
@js there is nothing sad about TOTAL AUTOCONF DEATH.
It's a huge pile of ugly hacks that needed to be killed with fire decades ago.
@icon_of_computational_sin @js from a packager’s PoV it’s a solved problem though, and "better the devil you know" than the dozens of other possible build systems. And I know js and @bentsukun and others agree and debhelper handles autoconf properly by default as well, easily. And packers know how to fix it.
@mirabilos @icon_of_computational_sin @js @bentsukun for the love of all that is holy, please stop with "better the devil you know", it's because of that attitude the *nix community is stuck with supporting ancient tools when with what we learned since their age we could move to much better ones.
I don't like Apple for a lot of reasons, but there is something about them I respect: when a tool needs to be cut off from life support, they do it. They say "no, fuck you, starting from MacOS x python2 / bash / whatever else won't be installed by default and supported by the OS, you can install them if you so wish, but anything you want to work on every OS install will need to move to the current century, thanks in advance". And it works, and after a brief period of catching up everything is nicer, faster and overall more based. Meanwhile you try to propose moving away from a tool so old it could've now had grand-grandkids were it a human in the *nix space and you're met with an impassable wall of screeching from people who knew nothing better their whole life and don't intend on changing it.
Software is moving extremely fast, in a decade we learn lessons and achieve things that allow us to make tools that the devs 30 years ago would've sacrificed both arms for. We need to use that power, or be doomed to still struggle with shit like autoconf in 2050.
@Amikke @mirabilos @js @bentsukun
from a packager's PoV, it's a Stockholm syndrome. Anyhow, NixOS somehow packages Meson and Cargo and Stack+Cabal and NPM and whatever other build systems have been invented just fine. And Debian is just an ancient atrocity, I wouldn't care about it in the slightest ever.
Then again, I did package maintenance for Debian-derived distros and it was one of the most miserable experiences of my life. If Debian follows the Autoconf suit, the world will be a lot better.
Darwinian evolution applies to software systems as well. Those that cannot adapt will just die and be replaced by those that can.