> 
> > If they have a
> > same-named file, such as make.inc on Unix, then those files will
> > overwrite each other.  How about having a "src/intplugins" hierarchy
> > that's just like the "src/plugins", except that it's for internal
> > instead of external plugins?
> That could probably be made to work, although it would be little tedious
> to rewrite. Maybe it would be simpler to add a unix subclas of VMMaker
> that understood the possiblity of these extra make.ic files and merged
> them? I'm curious what should be done when they are intended to be
> external though; presumbly something ought to be done with them? Is this
> in danger of invoking the 'recursive make considered dangerous'
> argument?


Hmm, you could do the merging in VMMaker, and it would be a lot nicer
than the shell script I've been using.  That's a nice idea!

Plugins that use external libraries are the ones that are likely to have
their own build rules.  For example, Mpeg3Plugin not only *uses* an
external library, but *builds* the library.  Also, VorbisPlugin appears
to be coming on the scene before long.  And I've thought GPGPlugin would
be nice, to hook into Celeste.  And so on.  Squeak is starting to reuse
some existing libraries, waddya know?

Really, in a nutshell, the idea is that external and internal plugins
are very similar.  They are going to be compiled almost exactly the same
way whether they are internal or external, and so it is convenient to
have the same directory structure each way.  But, I wouldn't want you
guys to have to redo the Mac and RiscOS platforms for it.



> 
> Perhaps this is another strong argument for OSProcess driving the
> compiler directly !


I don't think you want it running "cc' directly, because make's
functionality is really nice.  I don't think you really want to redo
make in Squeak -- while it sounds so simple, everyone who tries redoing
make ends up going on for months and then just posting what they have
and going on to something else.  Also, a lot of the autoconf code can't
easily be moved into Squeak; while autoconf is simpler than make, it's
still not something that seems worth fiddling with since it already
exists!

Still, parts of the build stuff could certainly be moved into VMMaker,
and firing "make" via OSProcess sounds very handy.  Hmm....


-Lex


PS -- in SHA, you should guess that the make rules aren't invoked
recursively -- the files are called make.*inc* for a reason. :)