[Vm-dev] VM Maker: VMMaker-dtl.302.mcz

David T. Lewis lewis at mail.msen.com
Tue Mar 12 20:45:40 UTC 2013


On Tue, Mar 12, 2013 at 11:25:23AM -0700, Eliot Miranda wrote:
>  
> On Tue, Mar 12, 2013 at 11:04 AM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
> 
> >
> > 2013/3/12 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> > > 2013/3/12 Eliot Miranda <eliot.miranda at gmail.com>:
> > >>
> > >> Hi Dave,
> > >>
> > >>     thanks, but...
> > >>
> > >> On Sat, Mar 9, 2013 at 7:06 AM, <commits at source.squeak.org> wrote:
> > >>>
> > >>>
> > >>> Item was changed:
> > >>>   ----- Method: VMMaker class>>versionString (in category 'version
> > testing') -----
> > >>>   versionString
> > >>>
> > >>>         "VMMaker versionString"
> > >>>
> > >>> +       ^'4.10.13'!
> > >>> -       ^'4.10.12'!
> > >>
> > >>
> > >> I *hate* the above.  It is busy work (it must be done manually before
> > each commit).  It is really easy to forget to do.  It is meaningless
> > (because it is easy to forget it makes no guarantee that it identifies a
> > unique version). It is not a good search key.  Mapping the version number
> > into the software configuration that produced the C code is hard (you have
> > to trawl through Monticello packages searching for the version with the
> > relevant version string; you can script this but fer christ's sake...).
> > >>
> > >> Using the Monticello package name and version (with the dirty marker)
> > on the other hand is automatic, is a really good key, and is meaningful.
> >  So please can we discard VMMaker versionString and move to using the
> > Monticello package?  Please?  Please.
> > >> --
> > >> best,
> > >> Eliot
> > >>
> > >
> > > +1, the two requirements are
> > > - automatic
> > > - meaningful
> >

The primary requirement is that it needs to work with Ian's cmake build
procedure in trunk, such that the build automatically creates a name for
the installation subdirectory, and such that the name corresponds to what
you see when you do "squeak -version".


> > However, there is also a dependency on external source (platform...),
> > and I think it is also included in COG id no?
> >
> 
> Yes.  To mark the generated sources, the Cog VMMaker does this:
> 
> For each source file generated, the Cog CCodeGenerator adds a comment
> containing the Smalltalk class and its VMMaker version that is translated
> to C and the Slang class and its version, e.g. from src/vm/gcc3x-cointerp,c:
> 
> /* Automatically generated by
>     CCodeGeneratorGlobalStructure VMMaker.oscog-eem.272 uuid:
> 8f4167f2-5bf0-4d90-9b7f-5355c741c68f
>    from
>     CoInterpreter VMMaker.oscog-eem.272 uuid:
> 8f4167f2-5bf0-4d90-9b7f-5355c741c68f
>  */
> 

This is a very good and useful thing, but unrelated to the intended use
of the version string.

I'm sure there are better ways to generate the version string, but it's
not something that I'm working on. Meanwhile, no we cannot discard the
versionString, and I'm happy to do the updates if other folks forget to
do so.

Dave



More information about the Vm-dev mailing list