Stephan,

Stephan Rudlof wrote:
> 
> Dear Rob,
> 
> Rob Withers wrote:
> >
> > 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.
> 
> I agree for platform independent files.
> 
> For platform dependent ones I don't know, probably both ways are similar
> good. But think of the possibility of different numbers of files for
> different platforms (for one platform it may be very complicated to
> implement mouse control with a special driver for it), for the other may
> be just one file... And the naming for the standard specific files
> needed from each platform has to be unique to switch automatically
> between them (and not in the plugin code!).

Mmmm..   It sounded like we were going to switch to a standard directory
structure, where the platform specific files are kept separate from the
plugin files.  When this happens then hopefully the special cases will
disappear.  We probably need an external project file to specify all of
the platform and helper files needed for each plugin, especially if
there are different numbers of files for different platforms.  The
VMBuilder can generate files from methods *in the
VMBuilder/VMConfiguration* or verify them in the correct dir location. 
I am going to leave my code as it stands unless there is a directory
structure change.

> > 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?
> 
> Agreed.
> 
> > 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.
> 
> Sounds difficult...

yes, but I'm certain that I am underestimating by a little too!   ;)

cheers,
Rob