ShellCLI module date

This may have been going on for a while but today I noticed it. Using today’s, 29Apr21, Titanium ROM a local build has ShellCLI showing a module date of :-

*help shellCLI
Module is: ShellCLI        0.38 (29 Apr 2021)

whereas the downloaded ROM shows :-

*Help ShellCLI
Module is: ShellCLI        0.38 (23 Nov 2020)

That ROOL’s build and mine differ is a bit of a concern, or at least a bit odd.

The dates in VersionASM and VersionNum are “23 Nov 2020” but the cmhg created ShellCLI.h.ShellCLIHdr has “29 Apr 2021”.

The answer is to be found here AcornC/C++.Documents.DDE.ChangeLogs.CMHG

Changes from CMHG 5.02 to 5.10
==============================

1) CMHG now gets the date for the module header from the datestamp of
   the CMHG input file, rather than using the current date. This will
   stop the silly situation of a simple rebuild producing something
   looking like a later version.

2) The date can be overridden using the new keyword "date-string:".
   For example:

       date-string:  26 Jun 1974

The fix is to add this to ShellCLI.cmhg.ShellCLIHdr :-

date-string:  Module_Date_CMHG

This line is present for other modules, should it also be present in ShellCLI?

Yeah, it should probably be added to ShellCLI.

My thanks to whoever committed the fix.

I rather enjoyed the explanation.

Ensures the date is consistent for anyone who doesn’t run the git-mtime.py script locally.

I am someone that does not run the git-mtime.py script locally.

git-mtime.py

I have now found git-mtime.py.

I tried first on RISC OS which with hindsight might not have been such a good idea!

git-mtime.py looks to be Python2, adding brackets around print data at least got it to run on RISC OS with Python3. It is obviously not going to work on an untar/bz2 unpack of a daily source code archive as all the git files get stripped out. A complete clone, copied with NFS from the Mac, and attempting to use either sgit or git, resulted in a git error.

The Mac does have Python 2.7.16 but I have not got git-mtime.py to do anything useful so far. It is not setting the the date stamp of cmhg.ShellCLIHdr to the commit date, if that is indeed what should be happening.

git-mtime.py is working. In particular is is setting the datestamp of cmhg.ShellCLIHdr to its individual commit date of 01May21, and that is the date that appears in ShellCLI if built without the date-string: override. I was expecting that datestamp reflect the date in the Version files.

The date-string: override does fix the issue.

I have now found git-mtime.py

It’s explained in the tips and tricks page, should you want to learn more. I’m amazed such functionality isn’t built into git, it seems such an obvious requirement for a source control system to preserve the timestamp, and 337,000 search hits say at least 336,999 other people think so too.

Specifically in the context of RISC OS the nightly builds run that script mostly so disc based stuff that embed ResourceFS areas come out the same every day, otherwise a new package gets created! CVS preserves timestamps, so that git-mtime.py is a convenience to mimic that.

The date-string: override does fix the issue.

For a CMHG module yes that’s another way to skin the cat.

There is a bit of an issue preserving timestamps when swapping between branches, which affects both compiled and semi compiled languages such as C/C++ and Python.

If you are working on Branch A and switch to Branch B which is older and time stamps are preserved, you have to do a make clean, so that any files from branch B with timestamps older than the corresponding object files from branch A are recompiled. If files in branch B are restamped when checked out, a simple make will recompile any files which have changed between the branches.

Most devs are aware of this when using makefiles, but less well known is it can affect Python. Python semi-compiles .py files to an intermediate .pyc, checking whether it needs to do this each time from the timestamps on .py and .pyc. So if you replace the .py with an older one, it will carry on using the .pyc from a different version, which can lead to some head scratching.

ResourceFS

Different datestamps can be seen in Resources: on comparing local builds, devoid of any git-mtime.py action, with ROOL’s properly built builds. This does not break anything, it is just a difference.

I’m amazed such functionality isn’t built into git, it seems such an obvious requirement for a source control system to preserve the timestamp

Fortunately in order to maintain some symmetry between a local RISC OS based build system and git the untar tool in !UnTarBZ2 also does not preserve datestamps. SparkFS does which then ducks the need for git-mtime.py on RISC OS.

I see git-mtime.py has been updated for Python3. Python 3.9 has now been installed on the Mac.