David T. Lewis
lewis at mail.msen.com
Wed Sep 2 22:12:48 UTC 2009
On Wed, Sep 02, 2009 at 02:38:05PM -0700, Igor Stasenko wrote:
> 2009/9/2 David T. Lewis <lewis at mail.msen.com>:
> > On Tue, Sep 01, 2009 at 08:43:19PM -0700, Andreas Raab wrote:
> >> Is it possible to have VMMaker create a vmmaker.h file that one can
> >> include to determine the VMMaker version the VM was generated from? It
> >> would be enough if it says, e.g.,
> >> #define VMMAKER_VERSION "3.11.3"
> i think, it would be much better to have:
> #define VMMAKER_VERSION "VMMaker-dtl.138"
> and also, maybe:
> #define VMMAKER_DATESTAMP "3 Sep 2009 10:05 pm"
Class VMMaker has a #versionString method that currently answers '3.11.3'.
The value is changed (manually iff I remember to do so) when changes are
made to the VMMaker package as a whole. This is a convention that Tim
put in place a long time ago (at my suggestion actually), so it now provides
a convenient way to provide an approximate version identification for the
VM source that is generated from VMMaker.
Ian has started identifying the Unix VM version (as reported in one of
the system attributes at run time) using a string consisting of the
VMMaker version and the Subversion revision level. This gives a reasonably
good identification of the platforms code plus VMMaker code.
Andreas suggested making the VMMaker versionString accessible as a
macro definition, presumably so that he can do something similar to
what Ian did, but without all the grepping and sedding. Hence this change
to add the VMMAKER_VERSION macro in a header file.
Generating the VMMAKER_VERSION macro is automatic now, so the only thing
that a person who updates the VMMaker package needs to remember is to
update the VMMaker class>>versionString method whenever something
significant changes in the VMMaker package.
More information about the Vm-dev