Stephan Rudlof wrote:
> 
> Please take a look onto the supportFile logic, which also could be a
> supportStream logic of course. It is an easy to use mechanism to define
> files, which behave to a plugin; not necessarily platform specific ones.
> There would also arise an error, if a - platform specific or not - file
> is missing, what is needed by a plugin.
> 
> An alternative would be to install a similar logic into a VMBuilder
> class hierarchy. Probably this would be better, since it would be more
> transparent and more flexible (say you have a different number of
> platform specific files for different platforms).


Keeping the names of dependent modules in the Plugin sounds right to
me.  The current locations and storage details should be resolved by the
VMBuilder I think.  For now we could have a VMBuilder classVariable
which would hold the current builder and a VMBuildConfiguration
classVariable which would hold a, ..., configuration.  This
configuration would provide the location details of the various modules
(local, ftp, cvs, http, Minnestore, ...) and be able to hold a build
environment config (gcc, cc, bcc32.exe, ...) and make utility config
(jam, make, autoconf, ...).  Then we could generate all support files
from the builder.  This would encapsulate the stream management to the
builder.  Does this sound like a good partitioning of logic for the
support files?

OSProcess would allow us to launch the builds and connect to stdin,
stdout, and stderr.  If there is a Window to display the shell then we
can display output and so on.  Once we've built a c, c++ development
environment, we can use the configurable parser that someone was posting
to allow for alternate syntaxes.  We could create a Python development
environment!  Well, I'm not really interested in that.  I would rather
build concurrent ObjectMemories in the VM.

Rob