[Vm-dev] About VM version string

Tue Apr 12 19:39:00 UTC 2011

On 12 April 2011 20:27, David T. Lewis <lewis at mail.msen.com> wrote:
>
> On Tue, Apr 12, 2011 at 10:14:07AM -0700, Eliot Miranda wrote:
>>
>> On Tue, Apr 12, 2011 at 4:58 AM, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>> >
>> > On Tue, Apr 12, 2011 at 12:53:20PM +0200, Igor Stasenko wrote:
>> > >
>> > > Hello,
>> > >
>> > > i'd like to know what we can do to clean up the mess with Cog VM
>> > > versioning, so people could identify it more easily.
>> > >
>> > > Currently , what
>> > >
>> > > Smalltalk vmVersion shows is:
>> > >
>> > > Smalltalk vmVersion
>> > >
>> > >  'Croquet Closure Stack VM [StackInterpreter
>> > > VMMaker-oscog-IgorStasenko.Stasenko.49] StackVM VM 4.0.0'
>> > >
>> > > but it doesn't says anything about which version of platform sources
>> > > are used to build it.
>> > > Also, a version number VM 4.0.0 makes no sense..
>> > >
>> > > I'd really like to see what we can do to improve it.
>> >
>> > (this may be a duplicate response, I'm having mail problems today)
>> >
>> > The mechanism used in the standard VMMaker and Unix platform sources
>> > works well in practice. This uses VMMaker class>>versionString to
>> > identify the (approximate) version of Smalltalk sources, combined
>> > with the Subversion revision number identified at compile time.
>> >
>>
>> I disagree.  I think its terrible.  It requires manual updating and hence is
>> essentially meaningless.
>
> We are talking about two different problems here. The purpose of the versionString
> and SVN tag is to give a simple label that can be used for "squeakvm -version"
> and to provide a name for the installation directory on unix systems. It
> is *not* intended to provide detailed version identification, and certainly
> would be a terrible approach if that had been the intent.
>
> Currently Cog on unix installs in a directory named for some three or four
> year old version of the standard interpreter VM, which is not a good thing
> (but maybe Igor has addressed this separately in CMakeVMMaker, I'm not sure).
>

No, i'm not addressed that, since i didn't added an steps in
configuration to install built artifacts.
I know that most *nix users would expect to be able to do
make install
after 'make' , but i think that it would be better to do proper
packaging separately (like 1-click package where you including VM for
different platforms , and hence simple 'make install' won't go
anyways), rather than messing with cmake..

Or perhaps i'm too lazy to do that :) so if anyone wants to include
that, give it a try.

> The UUID based identifications below are great, that was what I was
> trying to point Igor to in my separate email. I think that is an excellent
> way to make the detailed version information available.
>
Yes, indeed.

(Now i wondering where i could append a lil info, which could tell
which exactly config is used to build VM)

> Dave
>
>> The solution in Cog is to include the VMMaker
>> version along with its UUID, prefixed with an asterisk if the package is
>> modified (matching the Monticello UI's display of dirty packages).  This
>> tells one exactly which sources were used to generate the VM.  Here's an
>> extract from oscog's src/vm/cointerp.c:
>>
>> /* Automatically generated by
>>     CCodeGeneratorGlobalStructure VMMaker-oscog.54 uuid:
>> 73c095bd-7fa5-4ef9-b9fc-60378cae64c7
>>    from
>>     CoInterpreter VMMaker-oscog.54 uuid:
>> 73c095bd-7fa5-4ef9-b9fc-60378cae64c7
>>  */
>> static char __buildInfo[] = "CoInterpreter VMMaker-oscog.54 uuid:
>> 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 " __DATE__ ;
>> char *__interpBuildInfo = __buildInfo;
>>
>> And hence
>> (1000 to: 1100) select: [:i| (Smalltalk getSystemAttribute: i) notNil]
>> thenCollect: [:i| i -> (Smalltalk getSystemAttribute: i)]
>> { 1001->'Mac OS' .
>> 1002->'1067' . 1003->'intel' .
>> 1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54] Croquet Cog
>> 3.0.0' .
>> 1005->'Aqua' .
>> 1006->'Mac OS X built on Mar 31 2011 17:23:52 Compiler: 4.2.1 (Apple Inc.
>> build 5666) (dot 3)' .
>> 1007->'CoInterpreter VMMaker-oscog.54 uuid:
>> 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr  1 2011' .
>> 1008->'StackToRegisterMappingCogit VMMaker-oscog.51 uuid:
>> d213bf61-5898-475b-8a5c-e4a9bdad2415 Apr  1 2011'}
>>
>>
>> Now this could be improved upon by also including the uuid for the VMMaker
>> package in parameter 1004.
>>
>>
>> > For the VMMaker side, I'd suggest adopting a similar (manually
>> > maintained) convention for #versionString, but also add a
>> > suffix to identify a cog VM versus interpreter VM. Thus if
>> > the versionString is '1.2.3' the Cog VM might use '1.2.3c'.
>> > The suffix identifier is helpful in the near term for maintaining
>> > separate installation directories on unix, and possibly becomes
>> > irrelevant whenever we get the code bases merged.
>> >
>>
>> This is useless.  Manual versioning is essentially arbitrary and very easy
>> to overlook.  We have accurate version information in the Monticello package
>> version and, given the UUID and the dirty mark convention, provides concise
>> and precise info. IMO its the obvious solution.
>>
>> However, the platform sources are more problematic.  One huge irritation
>> with svn is that it doesn't provide a way of including the revision number
>> in source since revision numbers are allocated after check-out.  Instead one
>> has to derive the revision number y running a command, e.g.
>>
>> McStalker.oscogvm$ svnversion
>> 2219:2378M
>> McStalker.oscogvm$ svnversion | sed 's/^.*://'
>> 2378M
>> McStalker.oscogvm$
>>
>> Which might work on unix systems but is a nightmare on Windows, and requires
>> builders to use an up-to-date svn, and forces everyone to use svn.
>>
>> I don't know what the conventions are in git, mercurial, cvs etc.
>>
>> I think we need to develop some convention which is along the lines of the
>> platform build requiring the inclusion of some file that contains some
>> precise version info, and providing e.g. options in the makefiles for
>> generating there.
>>
>> e.g.  make platverforsvnunix
>> svnversion ../platforms | sed 's/^.*:/#define PLATREV /' >platver.h
>> svn info ../platforms | grep URL: | sed 's/^URL: \(.*\)$/#define
>> PLAT_REP_URL "\1"/' >>platver.h
>>
>> to produce
>> #define PLATREV 2376
>> #define PLAT_REP_URL "
>> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms"
>>
>> and then derive some system attribute from that, or include it in 1004, e.g.
>>
>> 1004->'Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.54
>> uuid: 73c095bd-7fa5-4ef9-b9fc-60378cae64c7 Apr  1 2011, platform: 2376
>> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms] Croquet Cog
>> 3.0.0' .
>>
>> We can then provide VMMaker and platforms info for any source code control
>> system with a little bit of effort on the builder's behalf, semi-automated
>> in that the makefiles can prompt (and provide help for) the builder to
>> create e.g. platver.h correctly.
>>
>> This kind of version info gives precise location for the sources and allows
>> reproducible builds.  The manually maintained version info is, frankly, a
>> joke.
>>
>> HTH,
>> Eliot
>>
>>
>> > For the platforms sources on the git mirror with CMMakerVMMaker
>> > build, some mechanism would be needed to identify version level.
>> > Ian's build procedure on unix with Subversion works well for
>> > this, but I don't know how to do the equivalent on the git
>> > mirror. But I'm not really familiar with git, so hopefully
>> > someone can suggest something here.
>> >
>> > Dave
>> >
>> >
>
>

-- 
Best regards,
Igor Stasenko AKA sig.