[Vm-dev] VMMaker[Tool] considered harmful

Andreas Raab andreas.raab at gmx.de
Sun Mar 28 20:30:28 UTC 2010


Folks -

This is probably not the best time to raise this issue but I've been 
increasingly unhappy about VMMaker over time (ask Eliot :-) From my 
perspective VMMaker is now a tool that gets more in your way than it 
helps. I'd like to make to make it *much* simpler. Here's what I think 
VMMaker ought to do:

* Translate a set of classes into C code in a specific directory.

Period. No fuzzing with second-guessing of absence or presence of 
platform or support directories, no upfront-decisions about what plugins 
to build internally vs. externally, no guessing about the layout of the 
files in a particular port, no copying files between unrelated directories.

In our internal Teleplace images (where we already do this) the usage of 
VMMaker has been reduced to the following expression:

	VMMaker
		generate: CoInterpreter
		to: (FileDirectory default pathFromURI: '../src')
		excluding:#(
			BrokenPlugin DShowVideoDecoderPlugin IA32ABIPluginSimulator
			NewsqueakIABIPlugin NewsqueakIABIPluginAttic
			QuicktimePlugin QVideoCodecPlugin QwaqMediaPlugin
			SlangTestPlugin TestOSAPlugin ThreadedFFIPlugin
			Win32OSProcessPlugin
		).

All plugins and the main VM are generated into ../src (or whatever 
directory you give it) and we provide a list of plugins not to translate 
(although strictly speaking that's not necessary). The result is a 
structure that looks like here:

<build root>/
	platforms/ <the vmmaker platform tree>
	src/ <shared generated vm sources>
	mingwbuild/ <windows mingw build specific>
         cygwinbuild/ <cygwin build on windows>
         mscbuild/ <MSVC build on windows>
	macbuild/ <mac build specific>
	unixbuild/ <unix specific build>
         "... and more builds ..."

Each of the *builds* then defines which plugins to use internal and 
which ones external (for example by modifying plugins.int and 
plugins.ext or by changing the appropriate build files) and takes 
responsibility for the location of the required support files.

To me, it makes really no sense to have half of the actions being done 
by VMMaker and the other half by the native build environment. Since a 
native build environment will continue to exist for the foreseeable time 
I'm advocating to abandon the use of the VMMaker in the way we're doing 
today and reduce it to simply a generator of C code.

Cheers,
   - Andreas



More information about the Vm-dev mailing list