"Rob Withers" <rwithers12 at mediaone.net> is widely believed to have written:


> that did it.  I deleted the sqUnixSecurity.c file.
Nah - got to remove the SecurityPlugin _directory_ since the existence
of the directory is currently the test. It could reasonably be changed
to test for the existence of a file in the directory, but I made a
simplifying assumption.


> These two are clearly related, right?   We are computing closures.
> Currently, you have already filtered unsupported Plugins, before we select
> them.  You direct the remaining plugins, from the platforms directory, to
> either the vm or the plugins directory in the src.  We would just need to
> undo some of those moves, before rewriting.  Undo is better than
> annihilating the entire src, because we may only want to regenerate part of
> the vm/plugins over the previous generation.   The second case, is a third
> set of plugins to intersect; those from the platforms directory.
I'd think adding a check to the methods that write the vm directory and
the plugins directory would probably do enough; if generating the core
vm, pre-delete vm/* and if generating external plugins, delete
plugins/*. Copare with the gymnastincs I have t perform to keep the
exportsList clean in cases where you for example generate a src tree
with a few internal plugins and then generate with different internal
plugins.

> 
> For example, your ideas of generating makefiles and projects for the
> compilers sounds like another homerun.  We could have a Builder hierarchy,
> with specifics for each build environment.
There is already a hierarchy for platform name - see RiscOSVMMaker for
example. I had to do some moderately tricky gymnastics to make sure you
get the right class if you change the platform name field!
> 
> PS.  Do you think we could get the OSProcessPlugin into the platform code?
I hope so. It's far too nice to leave out for much longer.

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- One sandwich short of a picnic.