Re: toolchain/58960: Missing support for _NETBSD_REVISIONID on various ports

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Mon, 06 Jan 2025 07:11:27 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
>
> That is, I read:
> 
> 	Currently we bake CVS/RCS revision numbers into objects from .c
> 	files with the RCSID("$NetBSD: ...$") and
> 	__KERNEL_RCSID(0, "$NetBSD: ...$") macros.  These macros should
> 	be adapted to process a _NETBSD_REVISIONID definition, which is fed
> 	in at the top level by build.sh.
> 
> as meaning that the _NETBSD_REVISIONID was going to replace the current
> string (presumably because neither got nor hg provide simple linear number
> identifiers for versions).   But that's not what is happening, rather, if
> _NETBSD_REVISIONID happens to be defined, it is *also* being included in the
> data baked into the objects, along with what is there now (or whatever
> modified version a git/hg checkout will end up producing - which I hope
> will be something, rather than simply ignoring these lines).   If
> _NETBSD_REVISIONID isn't defined, then nothing changes from what we have
> now (the way that gets done alters a bit, but that's immaterial).

Correct: This PR is about teaching the RCSID/__KERNEL_RCSID macros to
include _NETBSD_REVISIONID, without replacing what's already there, so
it only adds information.

The exact nature of the information to be added is yet to be
determined.  For now build.sh passes in a changeset hash when it runs
make(1).  I plan to do two things differently:

1. Use a more meaningful revision id that shows:
   (a) the latest tag, like netbsd-10.99.12;
   (b) number of changes since the latest tag; and
   (c) whether the working tree has changes or not.

2. Derive _NETBSD_REVISIONID when you run make(1) rather than when you
   run build.sh.

We might also contemplate other variations like recording some
information about make(1) prerequisites.  How much information is
worth putting into it remains to be seen.  ident(1) output has always
been a useful if limited diagonstic, never perfect, so we'll discuss
and experiment with what information goes in.

But this PR is only about whether the macros take _NETBSD_REVISIONID
and bake it into the object file so we have the opportunity to do that
experimentation.  So I'll close the PR when we're sure it's all
working and we can move discussion about what goes into
_NETBSD_REVISIONID elsewhere.