[Vm-dev] source version info

[David T. Lewis]

On Sun, Feb 06, 2011 at 12:34:53PM -0800, Eliot Miranda wrote:
>  
> Hi All,
> 
>     in building up to the VM releases for 4.2 I would like to add meaningful
> source info to all VMs in a consistent way.  The main rationale here is to
> know exactly what source a VM was built from so that there's a chance of
> recreating it, hence to be able to use gdb-style debugging tools against
> source, and reduced chance of putting out different VMs that answer the same
> version info.
> 
> There are two elements to the source info.  One is the VMMaker package.
>  This is in the Cog VMs in getSystemAttribute: 1007 (Interpreter class) and
> getSystemAttribute: 1008 (Cogit class, if any).  But there's no similar
> specific info for the ensure VM source (platform tree, and
> hopefully generated source aincluded in it).  Rather than just provide a
> revision in whatever version control system we're using I'd like us to use a
> url and a version identifier, e.g. "
> http://www.squeakvm.org/svn/squeak/branches/Cog 2359".  This could be
> getSystemAttribute: 1009 but that would probably break code that enumerates
> attributes until it gets an empty one since the StackInterpreter and
> Interpreter don;t have a Cogit class.  So, if there's agreement on including
> the url/version I would make that 1007 and move the Interpreter class and
> Cogit class to 1008 and 1009 respectively.   Since various version control
> systems don't necessarily provide a convenient way to derive the version
> info I suggest we modify the build system to include a file that is not
> included in the source tree that nas to be manually edited to contain the
> relevant string.  We can then provide helpful info close to the error
> location (when one tries to compile the file when its missing) that explain
> how to fill in the file.  (better ideas?)
> 
> Also, the three platforms define their version info SQ_VERSION and
> VM_VERSION in different places and using different mechanisms, which makes
> it hard to keep things consistent.  I'd like to see these defined in
> platforms/Cross/vm/ something (platforms/Cross/vm/sqVersion.h
> ? platforms/Cross/vm/sq.h?).  SQ_VERSION appears to be unused so I'm nuking
> it from the Cog sources.  Does this make sense?
> 
> 
> best
> Eliot

Hi Eliot,

The source url/version idea sounds like a good idea to me, whether
as a system attribute or as an optional primitive.

In the interpreter VM, there are three primitives:
 #primitiveInterpreterSourceVersion
 #primitivePlatformSourceVersion
 #primitiveVMVersion

Which are supported in the image thus:
 Smalltalk interpreterSourceVersion ==> '4.0.4'
 Smalltalk platformSourceVersion ==> '2343'
 Smalltalk versionLabel ==> '4.4.6-2343'

The value of interpreterSourceVersion is derived from VMMaker class>>versionString,
and the value of platformSourceVersion is derived from the Subversion
source version at configure time.

It would be good if you can make use of this mechanism for Cog and
StackInterpreter also, possibly modified in some way to identify the
Cog source branch (since the unix "make install" typically installs
in a directory identified by the version string, and Cog and SqueakVM
currently need separate install directories).

If you were to use VMMaker>>versionString and have it answer e.g.
"4.4.6c" rather than "4.4.6" that would probably be sufficient to
prevent install directory conflicts. Note that the VMMaker
versionString is simply method that is hand edited when the package
is updated, so it is by no means a robust mechanism. But in practice
it works fairly well. And there is no reason that the versionString
for Cog VMMaker should align with that of the standard VMMaker, just
as long as they don't conflict with one another in installations.

Dave