Edward Welbourne wrote: > >> All but one of those I've looked into is manifestly less powerful than > >> make (and I'm still waiting for my former colleagues to get the > >> exception released to open source). > > > I have no illusions that there aren't very serious issues with make and > > I have nothing bad to say about people who choose a different tool, or > > even write a different tool. Make is weighed down by standardization > > and history, so starting over from scratch has a lot of appeal. > > Indeed - and that's sorta the story behind my one exception - but I've > seen *many* claims of "this is *hugely* better than make" that were > grounded only in a profound ignorance of what make (or, at the very > least, GNU make, which was usually what they actually meant) could do.
Me too. It often appears to me they fixed one (real or perceived) problem they had with make, and neglected everything else, so the result is a specialized system suited for their own needs, but hardly useful for different kinds of projects. Yet they're often advertised as general make replacements. After seeing a number of them, and when faced with the decision what to use myself, I still came to the conclusion that using make was less painful, even though, like Paul says, it has some issues (*cough* tab as a significant character). That's even though I kind of despise the autotools with their autofoo upon autobar and generated files generated from other generated files, and spamming every source directory with lots of templates, generated files, and copies of most of the autotools themselves. I think the design is fundamentally flawed, they should have been made a library (of scripts, Makefiles, etc.) that other packages can use rather than forcing themselves into their distributions. Maybe it was a reasonable decision in the 1980s when GNU programs were usually built on proprietary Unix systems, whereas today they're often built on existing GNU-based distributions (Linux, Cygwin, ...) where an autotools library could have just been included, and for other systems, installing autotools would be an extra one-time job like installing a required source library. Anyway, it's getting off-topic, but my point is, everything I needed that automake could possibly have done for me, I was actually able to do with make features. Sure, I had to require GNU make (which is no problem since it's quite portable itself), but as they say, every problem can be solved with another layer of indirection, and since (GNU) make allows that (in variable names or with "define" or "include", e.g. for things like "Generating Prerequisites Automatically", which I did based on the way as described in the manual), so among other GNU make features, I could do all I need, without needing a make replacement, or layers of autotools. That makes GNU make still a valuable tool for me (even though without historical ballast it could have been even better, but the same goes for C, C++ and much else). So far I've had only two major wishes with regard to my build process: - "Correct" parallel builds, especially WRT output messages. This is now solved with output-sync (which brings this message back on-topic for a short moment :-). - That my Makefiles be readable. But I guess you can't have everything. ;-) At least I've put all the dirty stuff in one generic Makefile which is included from the individual Makefile which then are quite short and mostly trivial, usually just a bunch of variable assignments and a few straightforward local rules. So having one write-only Makefile in my codebase is just acceptable and certainly better than the alternatives I've considered. > Eventually I had a (bright young) colleague who was faced with a mess of > make-files (that I'd made less of a mess, so folk asked me about, > despite my reservations about how it was after my efforts) and tried > earnestly to make them better (as opposed to *less horrendous* - which > was my modest goal) a few times, then finally ended on the "we need > something better than make" road (and had the generosity to still ask me > for advice on that road) where he would have made the same mistakes I'd > seen several times over, but I told him about them; and he's done > something I want you all to see, mainly to get a less partial (he's my > friend and I helped him design it, so I'm very very biassed) view of the > tool he came up with. It *may* be better (*I* think it is, so does he, > and he's a smart lad) That sounds interesting. While we're on the topic I wonder, does it support parallel builds (I hope so, since for me, they're essential today and will only get more important, seeing the development of CPU frequencies and number of cores), and if so, how does it handle output from parallel jobs? _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make