On Sat, Jul 15, 2000 at 02:07:55PM -0700, Greg Stein wrote:
> On Sat, Jul 15, 2000 at 03:27:03PM -0500, Jim Blandy wrote:
> >...
> > `Recursive Make Considered Harmful' is an interesting paper, and he's
> > right that Make has been seriously outgrown these days. But his
> > solution was to write his own build tool, which is an option we don't
> > have. Using a build tool other than Make would discourage people from
> > building Subversion at all.
>
> Euh... can't you still use some of the non-recursive concepts with make? I
> don't see that we need to use his "cook" program.
If we're willing to require GNU make, we should have no trouble doing
nonrecursive makefiles. And if, as the automake people claim, all
modern make implementations have an 'include' directive, we might be
able to do it without requiring gmake - it'd just require more typing
in the subdirectory fragments, is all.
Cook has a cleaner syntax and more flexible pattern rules, but I
wouldn't consider that reason enough to switch. And it knows about
one rule building multiple files all at once (like yacc generating a
parser and a header simultaneously) which I've wanted added to gmake
for years. But again, that's not reason enough to switch.
A point in favor of recursive make is that you get the ability to
rebuild just one directory, for free. That is harder - not
impossible, mind - to arrange with nonrecursive make.
My ex-boss was opposed to autoconf because it meant he couldn't just
blindly type 'make' at the top level of a directory tree, and he had
to remember to edit Makefile.in instead of Makefile. Now he tended to
go overboard on things, but I do think he had a point. And if we are
willing to require GNU make, one of the things I'd like to try doing
with it is making that work again. It could be done by putting all
the autoconf substitutions in a separate file, which configure edits
and the top-level Makefile includes.
zw
Received on Sat Oct 21 14:36:05 2006