The class InterpreterSupportCode currently contains only the
Mac-specific
files.  I suggest that we create subclasses for each platform and
maintain
the port-specific code and build instructions as part of the Squeak
sources
(or at least, allow for platform-specific fileins).

We can group everything in categories like VMConstruction-MacPPC,
VMConstruction-Linux86, etc.  I am doing this for the slow-in-coming
EPOC
port, because I have to subclass the C Translator in order to deal with
EPOC's unique memory allocation requirements.  It would make sense to
put
the EPOC-specific C++ files into the Squeak sources and generate all the
C++
sources with "InterpreterSupportCode writeEpocSources." and
"EpocInterpreter
translate: 'interp.cc' doInlining: true."

writeLinuxSources (et al) can create source directory trees and
makefiles,
eliminating the organization problems Tim speaks of.  Each new porting
project can be made available as a change set, which is a more elegant
form
of source control than CVS, imho.  It would be nice if the official
Squeak
distribution contained sources for all the different VMs, but a
platform-specific change set would suffice.

Tim Rowledge wrote:

> There seems to have been some confusion over recent months about the
> layout of the VM sources; all the way back to the time people were
> attempting to setup the SourceForge site in fact. I'd like to offer some
> suggestions for a solution to the problem.
>
> One of the problems is that the files need to separated along several
> axes.
> a) generated vs 'hand-written'
> b) portable vs platform specific
> c) main VM vs external plugin
> d) a tree of platform specifc files for the large list of platforms we
> support.
>