(no title)
taylanub | 10 years ago
And packagers will everywhere will hate you for it.
I've recently written many GNU Guix package recipes, and packages using Autotools are the ones I tend to have the least headaches with. CMake and Waf are so-so I think, perhaps lacking in maturity, but I didn't have that much experience with them. Custom/hand-written Makefiles and ./configure scripts are the worst.
Just learn Autotools, get over the fact that they contain backwards-compatibility crud (that you can just ignore, or how does it hurt you?), and stop the FUD. Even if only targeting GNU and BSD systems, there is already enough diversity and library detection boilerplate to make it worth using a proper build system, and Autotools is the most mature one out of the bunch.
It's even more important for unconventional systems like Nix/Guix where software is to be built in very special ways, where hard-coded assumptions in build systems hurt, especially if a custom one; if it's a known one then even if hard-coded it will probably conform to some typical pattern of use of that build system so one can use tooling to automatically fix packages using that build system, and in the case of Autotools that isn't necessary in first place because everything is parameterized and flexible to hell and back.
Also please do use pkg-config. Like Autotools, it's not perfect either, but I could write another two paragraphs on how helpful it is in bringing consistency, toolability, etc. into build/packaging systems...
haberman|10 years ago
It doesn't require developers to run ./autogen.sh, or to have autotools installed (in their correct versions).
It doesn't contain obscene amounts of indirection, where the actual libraries live in a hidden directory called .libs (looking at you, libtool).
It doesn't make you write m4, or Makefile.am files with all these magic incantations. It doesn't make you delve into the guts of these crufty systems when things don't work the way you expect.
If you want build systems to satisfy your use cases, publish some doc of best practices and capabilities that all build system interfaces should provide. If I'm convinced I'll be happy to conform to the interface you need. But there is no way you're going to convince me that everyone needs to just keep using autotools (a specific implementation) forever. I hate them.
I mean, by that logic, why are you doing something new like GNU Guix when everybody already knows/uses APT, RPM, BSD ports, etc? "Just learn [them], get over the fact that they contain backwards-compatibility crud (that you can just ignore, or how does it hurt you?), and stop the FUD."
Or maybe it is worth breaking with the past sometimes, when you think you can do better.
taylanub|10 years ago
All of the things you list are annoyances with crud that exists to satisfy this or that use-case which I suppose you personally don't need, which doesn't mean they don't have purposes. I would also say they are all minor annoyances. Your builds run faster than a ./configure script? Not building particularly large projects I suppose. Installing autotools? Big deal! I don't know when one needs to write m4, but the Makefile.am format looks rather clean and minimal to me; I don't see how you could have something much cleaner without losing a lot of generality. And having to delve into the guts of some obscure system is exactly what I had to do a few times because some piece of software refuses to keep with the convention and just use Autotools.
The documentation you ask for is idealistic and unrealistic. GNU Autotools are free software, and with decades-old proven maturity; I see no reason not to use them. The only pseudo-reasons I see are NIH, FUD, etc.; the usual.
GNU Guix (and before that, Nix) is fundamentally different from all other package managers, so that analogy makes no sense here unless you have some radically different innovative build system.
jordigh|10 years ago