Lex Spoon wrote:
> 
> Rob Withers <slosher2 at home.com> 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.  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.
> >
> 
> It seems really easy to me to just establish a standard directory
> structure, and then load platform specific files on top of that and type
> "make".  Whatever more sophisticated system everyone comes up with,
> please try and keep it as easy as the simple scheme!

Absolutely.  This is what the new directory structure will give us,
right? Simplicity in the face of external/internal plugins and generated
vs. platform specific code/files.  The issue I was dealing with was the
lack of meta data about what this structure was.  Now it's hardcoded!
;-)

Rob
> -Lex

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!