| |||||||||||||
Hmm...Hmm...Posted Nov 7, 2011 8:56 UTC (Mon) by khim (subscriber, #9252)In reply to: Hmm... by alankila Parent article: libabc: a demonstration library for kernel developers
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.
(Log in to post comments)
|
|||||||||||||