"Lex Spoon" <lex at cc.gatech.edu> is widely believed to have written:

> Okay, I'm outnumbered on the copying issue, so I give in.  I've uploaded
> a new version of SHA that grabs everything from the src dir.
Don't think of it as giving in, more as a retreat until there is some
opportunity to really rework things; one day for example I'm sure we'll
be able to assume working links.
> 
> Still, just one small request on how the copying is done: why do all the
> internal plugins get smushed together in src/vm?
That's a simple one to answer; I didn't have any idea that there would
be separate makefile stuff for any plugin. Ergo no need to handle that
case was seen and no code was written. It seemed both simple and
adequate to stick all the files to be built and linked into the vm
executable into a single directory.

> 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?

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

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- She worries about the calories licking stamps and envelopes.