[squeak-dev] Re: Modular Plugins

Andreas Raab andreas.raab at gmx.de
Thu Dec 24 12:52:17 UTC 2009


K. K. Subramaniam wrote:
> On Thursday 24 December 2009 12:04:45 am Andreas Raab wrote:
>> K. K. Subramaniam wrote:
>>> A closer look at SVN shows
>>> only  unix/src/ and Mac OS/.. contain auto-generated files. Though why
>>> these intermediate files (but not their source .cs/.st files) are in SVN
>>> is a mystery.
>> For the same reason that these files are included in the build files on 
>> Windows as well. They allow one to recompile precisely the same version 
>> that was used in the binary you're using which is tremendously helpful 
>> for debugging.
> I find this confusing given David's earlier mail about .c files being an 
> intermediate file. How is this use case different from using -E option in C 
> compilers to get pre-processed output for debugging purposes? We don't put the 
> .i file into SVN. We simply generate it on demand from the .c file.

The main point of checking in these files is to have a reference that 
can be used to create *precisely* the VM that you're using, as close as 
possible. The same thing could be achieved by checking in all the 
VMMaker code into SVN and regenerate it from there. The choice of 
checking in the .c files is rather arbitrary in this context - mostly 
driven by the need to fire up an image, load VMMaker, configure it 
correctly, generate the .c files. Since we don't have good scripts to do 
that, it's somewhat risky to assume everyone will be able to load 
VMMaker in precisely the version, using precisely the configuration that 
was used for the original build, to recreate these files. Consequently 
they are being checked in as well.

> I used the following script SamplePlugin.st:
> -----
> Preferences disable: #warnIfNoSourcesFile; disable: #warnIfNoChangesFile.
> InterpreterPlugin subclass: #SamplePlugin instanceVariableNames: ''
>   classVariableNames: '' poolDictionaries: '' category: 'VMMaker-Plugins'.
> SamplePlugin translateInDirectory: (FileDirectory on: '/tmp/vmm')
>    doInlining: true.
> SmalltalkImage current snapshot: false andQuit: true.
> ---
> and could generate the SamplePlugin.c file with:
>   $ squeak -headless unix-3.11.3.image $PWD/SamplePlugin.st
> 
> The code refers to sqVirtualMachine.h, sqConfig.h, sqPlatformSpecific.h and 
> sqMemoryAccess.h. I suppose I can change the script to generate these files for 
> a given target platform, if necessary.

I would just check out the required support code and set things up 
accordingly. Something along the lines of:

/SamplePlugin
	/cross (check out of platforms/Cross/vm)
	/win32 (check out of platforms/Win32/vm)
	/unix  (check out of platforms/Unix/vm)
	/macos (check out of platforms/Mac OS/vm)

	/src   (your source code)

This way you can stay in sync with the relevant bits at squeakvm.org.

> What holds us back from using vmm as a code translator tool in build scripts 
> to translate .st/.cs files (checked out from Monticello or SVN) and its 
> supporting header files on the fly before compilation?

Someone has to do it. I suspect that the reason why this has never been 
an issue is simply that during development you always have an image open 
already so there's little practical need to make that scripted.

Cheers,
   - Andreas




More information about the Squeak-dev mailing list