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.