VMMaker[Tool] considered harmful

 
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

On 28.03.2010, at 22:30, Andreas Raab wrote:
>
> 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.

+1

In fact, this would be a nice step towards actually generating the sources using a headless image while building the VM ...

- Bert -

 
Andreas Raab wrote:
I agree.

But I'd like something else. Currently VMMaker is both for building the
whole VM and plugins. I almost never build the whole VM. And I build
small plugins all the time. I believe that the subset for building
plugins should be a separate package.

I don't mind loading the whole interpreter. But, for example, Cuis does
not include Balloon. So loading the Balloon plugin is not trivial, and
really not needed if I'm just building, for example, a LinearAlgebra plugin.

What I do is to strip out unneeded plugins in order to build a VMMaker
package that can cleanly load and run in Cuis.

Not a big deal, but something that could be addressed.

Cheers,
Juan Vuletich

 
On Monday 29 March 2010 06:34:05 pm Juan Vuletich wrote:
> Andreas Raab wrote:
> > Here's what I think
> > VMMaker ought to do:
> >
> > * Translate a set of classes into C code in a specific directory.
> But I'd like something else. Currently VMMaker is both for building the
> whole VM and plugins. I almost never build the whole VM. And I build
> small plugins all the time. I believe that the subset for building
> plugins should be a separate package.
+1 and +1 for both proposals. Most plugins are really small and the build
process can definitely be simplified further.

Most of the build happens outside the VM with the C toolkits. The first step in
a build script itself can invoke headless squeak to translate classes (or
slang code) into the build directory.

Subbu

 
On Monday 29 March 2010 06:34:05 pm Juan Vuletich wrote:
> But I'd like something else. Currently VMMaker is both for building the
> whole VM and plugins. I almost never build the whole VM. And I build
> small plugins all the time. I believe that the subset for building
> plugins should be a separate package.
Well stated. +1 and +1 for both proposals. I would also like to see the
launcher part separated from the VM core. The latter is best left as a
library.

Let the launcher code handle command line parsing, image file dialogs, picking
pathnames from env variables, *.ini files and pre-loading modules.

Subbu