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

[David T. Lewis]

On Tue, Mar 12, 2013 at 04:45:40PM -0400, David T. Lewis wrote:
> 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.
> 

... but perhaps I am just misunderstanding what you are saying. Are you
suggesting that we come up with some way to generate a version string
automatically based on the Monticello file name, such as '272' in the
example above?

confused,
Dave


> 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