Comment by bheadmaster
3 years ago
> I think one area where Free Software has failed so far is build systems
GNU Autotools (also known as GNU Build System) is fairly standardized in the GNU world. The build process for most GNU packages is simple:
./configure
make
make install
The FSF-endorsed GuixSD (a GNU system inspired by Nix) is also putting a lot of effort towards system bootstrapping[0] and deterministic builds[1].
Of course, there is still a lot of work to be done. But honestly, I'm very optimistic - the GNU system has gone a long way since its inception, and it's only getting better by the day.
[0] https://guix.gnu.org/en/blog/2020/guix-further-reduces-boots...
[1] https://guix.gnu.org/en/blog/2020/reproducible-computations-...
Autotools helps you nothing when it comes to dependencies. It will just fail, maybe with a useful error message, maybe not. INSTALL file might give you vague hints on what you might need, often imprecise, outdated or incorrect. It's all just manual human work from there. That's a huge problem for Free Software as it ensures that nobody bothers to build their own software, largely removing the one big benefit Free Software should actually have.
GuixSD is working on fixing that, but that's a relatively recent development and at the moment at least it's missing anything equivalent to Nix flakes, forcing you to essentially fork the whole OS when you want to change anything and making you heavily depend on a central authority again.
We are still years away from a point where you can just build Free Software yourself across all the platforms that are supported by it. Even Guix and Nix will bail out the moment you try to target Windows or Android, if they support it at all (Nix supports Windows a little via cross-compiling, but few packages will build successfully).
autotools works well if you are building on and for a standard linux system. However if you are building on bsd it might not work (often assumes make is gnu make). If you are cross compiling it won't work (I cross compile a lot of code, the odds that an autotools build works out of the box is almost zero). It probably won't work on windows either, though I have less experience there.
That hasn't been my experience at all. I use Autotools on all of my personal projects that are C or C++, and I deal with all kinds of build systems in my day-job doing embedded Linux work.
Autotools goes to extreme lengths to maintain portability across Unix-like systems. That's kind of its whole deal, and it's the reason why people choose it. It's also better at cross-compliation than any other build system I've used.
There are lots of packages out there that have some kind of ./configure script or a Makefile. But they're not all fully Autotoolized, not by a long shot.
Autotools is designed for the problem, and CAN solve the problem. However my experience is it doesn't because the developers don't understand how to make it work and so they mess things up.
I have good luck with cmake for the same problem. It took me a while to write the toolchain file, but now porting a new cmake project just works.