| |||||||||||||
Hmm...Hmm...Posted Nov 7, 2011 0:31 UTC (Mon) by raven667 (subscriber, #5198)In reply to: Hmm... by khim Parent article: libabc: a demonstration library for kernel developers
Nope, automake is not my favorite thing... Ah, no objections here. Automake is horrible. But it's standard - and that's what counts. Kind of reverse to the usual saying: all automake projects are unhappy - but they are unhappy in the same way, all CMake/scons/whatever projects [may] be happy (I'm not sure), but they are happy in their own way and demand induvidual approach. This is exactly. The point that lennart seemed to be trying to make, not that autotools are particularly awesome but that they are a de-facto standard. Downstream users such as sys admins, packagers, automated build tools, etc know how to deal with automake and not any other flavor of the week systems.
(Log in to post comments)
Hmm... Posted Nov 7, 2011 3:09 UTC (Mon) by alankila (subscriber, #47141) [Link]
Maybe it would be possible to make autotools not-crappy by adopting a similar strategy as with cmake:
1) treat configure.ac as the definition of project's compiling rules, like the CMakeList.txt file;
It's obvious that a whole lot of the functionality of autotools would be lost, but maybe this transition would nevertheless be worth it. Because my experience with autotools is that every time this tool updates, there's always a project which no longer builds because something that used to work doesn't work anymore for whatever reason. And it's surprisingly hard to force autotools to rebuild all of its intermediate files, which makes debugging autotools build issues doubly frustrating.
I think autotools' problem is the fundamental design on utility written in one programming language generating code to be run with another programming language that generates code/data for yet more programming languages. Use of code generators always seems to result in an unworkable mess, so they really ought to be off the table. (Ideally there would not even be a Makefile as the output, but maybe that file is acceptable enough...)
Hmm... Posted Nov 7, 2011 8:56 UTC (Mon) by khim (subscriber, #9252) [Link] Maybe it would be possible to make autotools not-crappy by adopting a similar strategy as with cmake. No, it'll not work. compiling system uses this new utility, let's call it "fastconf", to read configure.ac and directly generates Makefile without ever invoking shell, m4, or generating any other files; You've lost me here. How the usual sequence of "./configure ; make ; make install" work after that? How your system will interoperate with other packages? It's obvious that a whole lot of the functionality of autotools would be lost, but maybe this transition would nevertheless be worth it. No. You'll just create N+1 build system which will be ostracized by distributions and avoided if at all possible. Sure, if you are large and established package (like KDE) you can push whatever you want - people will grumble but accept it - but if it's just a small library without a lot of cheerleaders then it's not a good choice. Note how similar approach (let's redo everything and drop bunch of features to make everything better) is "welcomed" by GNOME community (we have long thread right here) or by KDE community (well, it happened few years ago so the screams are not were loud now). The important prerequisite for that approach is abandonement of "old style": only them you can push "new style" down the [unwilling] peoples throat. And I don't believe people plan to abandon autotools support. Because my experience with autotools is that every time this tool updates, there's always a project which no longer builds because something that used to work doesn't work anymore for whatever reason. Funny. I experience this phenomenon with "modern" build systems, too. In fact (if you count number of autoconfiscated projects and number of projects built with "modern" tools) I'd say autotools are more robust. Distribution cope with this problem just fine: they just provide few versions of autotools and allow selection. Use of code generators always seems to result in an unworkable mess, so they really ought to be off the table. (Ideally there would not even be a Makefile as the output, but maybe that file is acceptable enough...) Somehow in my experience the worst problems arose from systems like SCONS which replace make completely. Autotools are in fact the most robust solution - simply because it's big changes are in the past, today it's mostly small bugfixes.
|
|||||||||||||