Source Tree/Repository revision info for the VM [was Re: [Vm-dev] new Cog VMs available]

Sat Jul 16 20:28:44 UTC 2011

On Sat, Jul 16, 2011 at 12:15 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>
> On 16 July 2011 01:48, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>> Hi All,
>>
>>    I juts committed a workable scheme for including version info in
>> the VM and the Mac .app, checked in on
>> http://www.squeakvm.org/svn/squeak/branches/Cog.
>>
>> - I've added a file platforms/Cross/vm/sqSCCSVersion.h which is
>> included by the platform files that answer the Smalltalk
>> getSystemAttribute: information (sqMacMain.c sqUnixMain.c &
>> sqWin32Window.c).
>>
>> - I've modified the getSystemAttribute: code to answer the revision
>> and repository URL in response to getSystemAttribute: 1009.
>>
>> - I've added a check-in script that makes sure sqSCCSVersion.h is
>> updated (if the script is used) so sqSCCSVersion.h's revision number
>> is up-to-date.
>>
>> So now e.g. Smalltalk getSystemAttribute: 1009 answers 'r2461
>> http://www.squeakvm.org/svn/squeak/branches/Cog'
>>
>> The scheme in sqSCCSVersion.h is simple and I hope extensible to other
>> repositories such that it is the only file that needs to fork between
>> repositories, and then only by altering the following lines to choose
>> the relevant repository:
>>
>> #define SCCS 0
>> #define RCS 0
>> #define CVS 0
>> #define SUBVERSION 1
>> #define BAZAAR 0
>> #define MERCURIAL 0
>> #define GIT 0
>>
>> e.g. choosing the repository on the command line via a Makefile means
>> changing lots of makefiles.  So this approach, while not ideal, having
>>  file different between different repositories does localise the fork
>> to just one file.
>>
>> Here's sqSCCSVersion.h in its entirety.  It computes char
>> *sourceVersionString(), which is that above.  If this approach makes
>> sense to people we can a) standardise on an attribute number (I chose
>> 1009 as the next unused number but am open to change if there's a good
>> reason), and b) extend sqSCCSVersion.h with the relevant sccs-specific
>> code to collect revision and url information for each specific
>> repository.  Thoughts, comments?
>>
>
> I am a bit puzzled by the code.
> Why you need a function to evaluate the version string?

Because in Subversion the expansion of any of the revision, author,
url, etc includes the keyword.  Unlike e.g. SCCS there is no way to
get it to expand the revision to just the revision number.  It will
always have to expand to "$Rev: 1234 $" and so must be parsed to
extract "1234".  The functions hopefully provide sufficient generality
to work with any version control system.

> If you taking stings from defines, like:
>
> #define URL "abc"
> #define VERSION "123"
>
> then you can just do
>
> #define VERSIONSTRING URL VERSION
>
> static char* versionstring = VERSIONSTRING;
>
> or not?
>
>> HTH
>> Eliot
>>
>> /*
>>  * A set of definitions for C source code control systems, to provide accurate
>>  * and definitive version information to the VM.
>>  *
>>  * Currently instantiated only for Subversion.  Please add definitions for
>>  * other repositories as appropriate.
>>  *
>>  * I guess a good way to manage this is to edit the below define list to select
>>  * appropriate the repository type, and then that's the extent of the fork.
>>  *
>>  * Eliot Miranda
>>  * eliot.miranda at gmail.com
>>  * 15 July 2011
>>  */
>>
>> #define SCCS 0
>> #define RCS 0
>> #define CVS 0
>> #define SUBVERSION 1
>> #define BAZAAR 0
>> #define MERCURIAL 0
>> #define GIT 0
>>
>>
>> #if SUBVERSION
>> static char SvnRawRevisionString[] = "$Rev: 2461 $";
>> # define REV_START (SvnRawRevisionString + 6)
>>
>> static char SvnRawRepositoryURL[] = "$URL:
>> http://www.squeakvm.org/svn/squeak/branches/Cog/platforms/Cross/vm/sqSCCSVersion.h
>> $";
>> # define URL_START (SvnRawRepositoryURL + 6)
>>
>> static long
>> revisionAsLong() { return atol(REV_START); }
>>
>> static char *
>> revisionAsString()
>> {
>>        char *maybe_space = strchr(REV_START,' ');
>>        if (maybe_space)
>>                *maybe_space = 0;
>>        return REV_START;
>> }
>>
>> static char *
>> repositoryURL()
>> {
>>        char *maybe_platforms = strstr(URL_START, "/platforms");
>>        if (maybe_platforms)
>>                *maybe_platforms = 0;
>>        return URL_START;
>> }
>> # undef REV_START
>> # undef URL_START
>> #else /* SUBVERSION */
>> static long
>> revisionAsLong() { return -1; }
>>
>> static char *
>> revisionAsString() { return "?"; }
>>
>> static char *
>> repositoryURL() { return "unknown"; }
>> #endif /* SUBVERSION */
>>
>> static char *sourceVersion = 0;
>>
>> static char *sourceVersionString()
>> {
>>        if (!sourceVersion) {
>>                int len = strlen(revisionAsString()) + strlen(repositoryURL()) + 3;
>>                sourceVersion = malloc(len);
>>                sprintf(sourceVersion,"r%s %s",revisionAsString(),repositoryURL());
>>        }
>>        return sourceVersion;
>> }
>>
>>
>> On Fri, Jul 15, 2011 at 9:27 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>> Hi Bert,
>>>
>>> On Thu, Jul 14, 2011 at 12:45 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>
>>>>
>>>> On 13.07.2011, at 22:56, Eliot Miranda wrote:
>>>>
>>>> > Hi All,
>>>> >
>>>> >     find new Cog VMs in http://www.mirandabanda.org/files/Cog/VM/VM.r2459/.  These have functional ALien callbacks.  Previous VMs had buggy code that could easily crash when heavily stressed, as discovered with Vassili Bykov's native Hopscotch UI in Newspeak on Win32.
>>>>
>>>> Hi Eliot,
>>>>
>>>> do you keep a continuous changelog somewhere for your releases? It would be nice to include that in the VM.
>>>>
>>>> Also, your Mac VM bundles always have the same version number which is somewhat inconvenient. Would be nice to splice the release version into Info.plist.
>>>
>>> I think I've found what's required:
>>> http://stackoverflow.com/questions/206183/how-can-i-force-subversion-to-commit-an-unchanged-file
>>> In particular
>>>
>>> If you want the file contents to remain unchanged you can always
>>> change one of the properties on the file.
>>>
>>> eg.
>>>
>>> svn propset dummyproperty 1 yourfile
>>>
>>> hence "Use Case: A file (config, xml, etc.) is chosen as a canonical
>>> version beacon for other apps. It indicates that "the code queried
>>> represents version rXYZ in SVN". Using SVN's macros on commit ("$Rev:
>>> xxxxx $") would be ideal for these purposes, provided SVN would deign
>>> to update an unchanged file. – pcorcoran"
>>>
>>> So I can now force a change to each Info.plist file and embed the Rev
>>> property.  I can also embed the Rev property in relevant .c or .h
>>> files to cause the Rev property to show in the relevant VM version
>>> strings.
>>>
>>> And I can fire off the svn propset via a precommit hook.  What I can't
>>> do is make this corss-platform.  It'll work on unixes but fall flat on
>>> e.g. Windows wirth TortoiseSVN.  Unless anyone knows better.  If so,
>>> let me know.
>>>
>>>>
>>>> While I'm in nitpicking mode: CFBundleVersion is recommended to be a simple integer, incremented for each bundle release - your "2459" might serve fine. This is not shown in the UI. The Finder shows CFBundleShortVersionString and the Get Info dialog shows CFBundleGetInfoString. Both of these are free-form as far as OS X is concerned, you can put anything you want in there. "Smalltalk vmVersion" includes CFBundleShortVersionString so there may be users expecting a certain format.
>>>>
>>>> Your current CFBundleGetInfoString has a link to a "boutique web design" company. I'm almost certain that's not what you wanted to put in there.
>>>>
>>>> In other words: Thanks for the new release ;)
>>>>
>>>> - Bert -
>>>>
>>>
>>>
>>>
>>> --
>>> best,
>>> Eliot
>>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

-- 
best,
Eliot