Skip to content

Improve cmake vdate depends #517

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 20, 2024
Merged

Improve cmake vdate depends #517

merged 2 commits into from
Nov 20, 2024

Conversation

nbriggs
Copy link
Collaborator

@nbriggs nbriggs commented Nov 20, 2024

Updates CMakeLists.txt so that vdate.c does not get rebuilt if no files have changed.
Updates bin/mkvdate to incorporate a git version stamp (if git is present and the source is under
git control), along with an indication of whether the directory under git control is clean or dirty.

const char *MaikoGitVersion = "maiko git version: 96046c0-dirty";

This information is NOT accessible from Lisp, but can be extracted from an ldex/ldesdl with a debugger
or by searching for the string "maiko git version" in the executable.

…nged

Creating vdate.c/vdate.o should not be done unconditionally.  It is only
necessary to recreate it if one of the input files has changed.
The variable MaikoGitVersion will contain a git revision from the head of the source tree
along with an indication if the status was "dirty".  If git is not present on the system
or the directory that the build happened in was not under git control the version will be
"none".
@nbriggs nbriggs requested a review from hjellinek November 20, 2024 19:42
@hjellinek
Copy link

Approved. I use something similar in my Java (Gradle) projects. It would be slick if this information were accessible from Lisp core - but not as part of this PR.

@nbriggs
Copy link
Collaborator Author

nbriggs commented Nov 20, 2024

Yes, making it visible from Lisp would be good. I'd probably change the format of the version string too. It's not trivial to create a new string in Lisp space from the C side, anything that does that tends to overwrite the characters of an existing string when the variable gets passed down to a subr. The BCPL username is a special case, where there are 32 words allocated in the interface page at a known offset, and we just fill it in and then adjust the layout to account for byte swapping.

@nbriggs nbriggs merged commit 89b2b4f into master Nov 20, 2024
@hjellinek
Copy link

If we cheat by making the version a "semantic versioning" triple of integers, would it be easier? For example, version 1.2.3 would be represented as the three numbers (unsigned bytes, really) 1, 2, and 3.

@nbriggs
Copy link
Collaborator Author

nbriggs commented Nov 20, 2024

Doesn't help too much with a Git commit hash. There is already a Maiko build date, and version numbers Lisp, "microcode", and BCPL --

        DLword    lversion;  // access via (LISPVERSION)
        DLword    minrversion;
        DLword    minbversion;
        DLword    rversion; // access via (MICROCODEVERSION)
        DLword    bversion; // access via (BCPLVERSION)

The MDate (the Maiko build date) is used to set the rversion as (MDate - 561150000) / (60 * 60 * 24), it's converting it to number of whole days since 12:00 13-Oct-87 -- Takeshi's birthday.

And, as the comment says in ldsout.c --

The sysout's ifpage.lversion must be >= LVERSION, and
the sysout's ifpage.minbversion must be <= MINBVERSION

Where the LVERSION and MINBVERSION constants track each other in the Maiko code with values of 15000, 20000, 20100, 21000, 30000, 35000, and 35010, but the ifpage.lversion is currently 39424 - the only place that gets set is by DUMPINITPAGES called under MAKEINIT if versions are passed to it. I would love to see the MAKEINIT dance written down. 39424 seems to come from internal/loadups/MAKEINIT. There was code in the old PARC-INIT which was setting up the local patch directories, and when passed "Medley" as the release name used 39424 to distinguish between "Medley" (it seems 39424 represented Medley 1.1) and "Medley1.15" (any other LVersion). I guess 39424 never got updated with newer Medley versions, but we set up the site init files to do the right thing.

@hjellinek
Copy link

True, git revision hashes have to be strings to be useful.

The rest of the explanation is great stuff and should be included in Maiko documentation , if it's not already.

@nbriggs nbriggs deleted the improve-cmake-vdate-depends branch December 3, 2024 17:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants