Let me try and summarize instead of doing a point by point.  There are
two main things I wanted in your system that you have not emulated from
the SourceForge stuff: integrated makefile, and support for scripts.

It turns out that you do support scripts after all.  You can run them
via autoconf, right?  That's fine with me, and so that issue is moot.  I
don't even see a need for an extra syntax for running scripts --
autoconf already includes it.


I still thing an integrated makefile would be better, however.  Your
strongest argument is that some compilers can't handle commands like "cc
-c somedir/foo.c  -o otherdir/foo.o".  However:

	1. It's probably rare.  How many people *really* have such a compiler? 
If we want more portability, there are bigger problems, I'm sure, than
the existence of such limited compilers.

	2. It can be worked around with a wrapper script, even when it happens.
 Maybe even libtool can do it.

	3. Most of us are using gcc, which doesn't have the problem.  Even on
systems with a better compiler that gcc, your Squeak VM is likely to be
faster if you use gcc due to your "gnuification" script.

Incidentally, I don't see what is atypical about your recursive make
setup.  You have multiple makefiles that each hold some of the
dependencies, and you handle this by having "make" re-invoke itself at
the right spots.

You do argue that you have gotten all the dependencies correct, and I'll
believe it.  However, it is a continued drain to maintain the
dependencies in this more complex fashion.  Instead of simply saying
"target : source" to say that "target" depends on "source", you must
additionally have rules to reinvoke "make" at appropriate locations.  Right now
this isn't terribly difficult, but there is no guarantee that it will
remain so.  For example, imagine that a top-level subdirectory builds a
tool that several plugins use; imagine changing one file in that
directory and then typing "cd FooPlugin; make".  Does the tool get
rebuilt, or does the plugin build with an old version of the tool?  It
is nice to avoid thinking about things like this.  "make" was built to
handle such concerns, but it needs to see all the dependencies at once
in order to do so.


In short, the conceptual simplicity and the avoided dependency problems
are plentiful reasons, IMHO, to use an integrated makefile.  I find it
so even if we have extra difficulties with some compilers -- after all,
there always will be some compilers we have trouble with.



Incidentally, it's not critical, but:

> His arguments are flawed (in the context of building Squeak) for two
> reasons.  First is that, in order to cope with having the flexibility of
> recursive make in a single makefile, he assumes GNU make -- and we don't
> have that luxury. 

The paper I cited does use GNU make features, but my system doesn't --
it concatenates the files with shell-script code.  In fact, the use of
scripts makes it easier to avoid all kinds of GNU make features (and
even generic-make features).  For one example, instead of pattern rules
like "foo/%.o : blah/%.c", or even ".c.o:" -- which are a common
debugging headache -- you can use a "for" loop in the script and spit
out all the individual rules.  

The difference is subtle difference and it's not key to the argument. 
But it's an interesting point, I think.  Scripts aren't at all overkill
for makefiles; in fact, replacing pattern rules by for loops, and using
subroutines, offer big *simplifications* in almost any makefile beyond
20 lines or so.  It took me a while to hit upon it, but "make" really
seems best treated as a target language.  That way, "make" can focus on
its dependency handling, and you can  let a real programming language
handle things like loops and subroutines.


-Lex