Copying version numbers into Messages files

I’ve been looking at: http://www.riscosopen.org/tracker/tickets/172

As I’m currently working on a component that also doesn’t update its messages file with the version number automatically. Looking at the whole of the currently available source tree, I believe that there are plenty of other components that also have this problem.

I’ve looked at the code in SciCalc’s MakeFile:

        ${GETVSN} SciCalc$Build$Major SciCalc$Build$Vsn SciCalc$Build$Date
        ${CP} ${LDIR}.Messages   Messages              ${CPFLAGS}
        echo VersionNum:<SciCalc$Build$Vsn> (<SciCalc$Build$Date>) { >> Messages

This is different from most of the existing applications which use an awk script in their build directory. (Alarm, and ChangeFSI for example)

I feel that the SciCalc method is unlikely to be portable to cross compiler environment. I’ve also noticed that it uses the RO4 style date v.nn (%DY %M3 %CE%YR) unlike the awk script’s v.nn (%DY-%M3-%YR). Ironically I actually prefer the RO4 format, but it does show the problem of doing this in an ad hoc way.

Rather than sprinkle awk scripts throughout the whole source tree. I propose a single script in the build environment. The only thing stopping this at the moment is that every app seems to use a different token for its version string. I therefore also suggest changing them to use the token _Version (chosen because the Configure-plug-in’s require it)

In the makefile instead of:

        GNU.gawk -f awk.Version LocalRes:Messages > $@

You would then need:

        GNU.gawk -f build:AwkVers LocalRes:Messages > $@

# Change _Version token in Messages file
# to Module_HelpVersion in VersionNum file

BEGIN {
    while (getline < "VersionNum" > 0) {
        split($0, Version)
        if (Version[2] == "Module_HelpVersion") {
            split($0, VString, "\"")
       }
    }
}

/^_Version/ { printf("_Version:%s\n", VString[2]); done = 1; next; }

{ print }

END {
    if (!done) {
        printf("_Version:%s\n", VString[2]);
    }
}

That said, I would like to be able to fix components before sending them in, rather than leaving it to Steve. So I’d like to establish a preferred method in advance. Which do you think is the best method?

I hold my hands up with the SciCalc makefile bodge – it was just a quick way of resolving an open bug against the component in a way that meant I wouldn’t have to worry about its version number again.

On the wider issue, you are right that it is something which should be centralised. I would suggest that the Awk script is the correct way forward, and to put it into Library.Build. You would then have the script itself defined in the shared makefiles (BuildSys.Makefiles.StdTools) just as GETVERSION is – not that I looked that far when I modified SciCalc. Something like:

MSGVERSION     = ${AWK} Build:AwkVers

I agreed that the RO4 date format is the way forward. We should try to ensure that everything uses that rather than the crusty old DD MMM YY format.

Finally, there’s the fairly simple matter of going through the repository and fixing everything which has some other way of performing this task so that it uses the new centralised Awk script.

If you don’t mind fixing everything, I can make the above changes to the BBE. Note: you have to be careful that in making the mods 1. the component still builds and 2. any assumptions it makes still hold (e.g. icon buffer size for version/date in templates files, etc).

If you don’t mind fixing everything, I can make the above changes to the BBE. Note: you have to be careful that in making the mods 1. the component still builds and 2. any assumptions it makes still hold (e.g. icon buffer size for version/date in templates files, etc).

Erm, I can’t volunter to fix everything at the moment. ;)

But I’ll add the AwkVers file to my Library.Build and use it for the new version of Maestro. There will be yet another version of Alarm soon which I’ll also fix.

I think I might have propagated a few awk scripts around, sorry. However, I did get a slap when changing date strings to be similar to RO4 (though note only a few RO4 apps got changed) – apparently the Style Guide dictated the format which is why the VersionNum files have both an application date and module date. I even added code to the task manager to parse the output of *FX0 and translate it!

Well I won’t be slapping anyone – unless I find their changes stop something from building.

I think complaints have historically arisen from resistance to breaking the consistency of the UI. One of the nice things about the RISC OS desktop is the consistency between application UIs, but one of its problems is the way this was achieved – by getting everyone to do separate implementations to match the Style Guide. The result is that it’s very hard to theme the desktop, compared to other OSes. The Toolbox goes some way to address it, but it really came too late and never became ubiquitous. Using a centralised awk script for all ROOL components makes consistent changes across all ROOL apps easier, but it’s never going to address the fact that loads of third-party applications out there which follow the Style Guide won’t match, and the chances of persuading their authors to produce new versions just for the sake of changing the date format is almost nil.

One way to address this would be to insert some sort of filter into window creation to identify the appropriate icons in program info boxes and rewrite the date into the user’s preferred date format, though this is quite a hacky solution to what is really a cosmetic problem.

If we’re going to set ourselves up as some sort of new Style Guide authority, let us at least carefully consider and discuss any changes made. In this case, there is a genuine problem in that the current ROOL mechanism (and possibly that used by other authors out there too) is not easily internationalisable. I propose one of the following solutions:

1) Use the format output by SWI Territory_ConvertStandardDate for the current territory. This would require applications to know their release date as centiseconds since 1 Jan 1900 (or at least be able to work it out) and to create their date string at run time. Downside is this requires code changes to lots of applications, upside is it’s globally themable.

2) Use ISO dates. For example 2008-10-06.