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:
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.
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
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Juan Vuletich -
K. K. Subramaniam