VM source stucture
Edward P Luwish
eluwish at uswest.com
Mon Oct 2 21:57:17 UTC 2000
The class InterpreterSupportCode currently contains only the
files. I suggest that we create subclasses for each platform and
the port-specific code and build instructions as part of the Squeak
(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
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
the EPOC-specific C++ files into the Squeak sources and generate all the
sources with "InterpreterSupportCode writeEpocSources." and
translate: 'interp.cc' doInlining: true."
writeLinuxSources (et al) can create source directory trees and
eliminating the organization problems Tim speaks of. Each new porting
project can be made available as a change set, which is a more elegant
of source control than CVS, imho. It would be nice if the official
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
> 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
More information about the Squeak-dev