On Nov 7, Levi Pearson wrote: > Although I agree in general that the implementation of autotools is an > unholy mess, I just want to point out that the "user interface" for > the developer is far simpler than the generated makefiles that ship > with release tarballs might suggest, and it's got reasonably good > documentation on how to use it. If you consider the world it was > developed in, where every UNIX-like system had vastly different sets > of available system libraries, it provided a *huge* advantage over the > typical manually-managed makefile. It's also pretty well-maintained, > so if you're largely targeting POSIX systems and you can ignore the > fact that it's implemented via a gigantic pile of M4 macros, it's > still a good solution for writing portable/configurable code in C.
At one point I was tempted to revise or rewrite automake to emit non-recursive makefiles[1], but quickly became daunted by the massive amount of work involved. I'm not sure how many of the crufty quirks, bugfixes, workarounds, and obsolete but actively used interfaces would need to be preserved. On top of that, a good non-recursive make structure is itself difficult to write, though a few people have managed to put together solid frameworks.[2] If I ever again delve deeply into C land, I might take up the cause in earnest. Building LFS with the new automake would be a decent test case, right? [1] http://miller.emu.id.au/pmiller/books/rmch/ [2] http://stackoverflow.com/questions/559216/ - Eric /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
