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

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR toolchain/58960; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/58960: Missing support for _NETBSD_REVISIONID on various ports
Date: Mon, 06 Jan 2025 07:11:27 +0700

     Date:        Sun,  5 Jan 2025 22:30:02 +0000 (UTC)
     From:        "Thomas Klausner via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20250105223002.C83951A923B%mollari.NetBSD.org@localhost>
 
 
   |  I think you leave the path of what can be supported here.  If you
   |  start copying in files, then they might not have any CVS or RCS or
   |  whatever identifiers, and you'll be on your own wrt to keeping track
   |  of what files in particular a binary is using.
 
 The files copied are the same ones that would be compiled by build.sh
 and have the exact same __RCSID() as would "normally" be used.  If an
 updated file gets copied, then its updated __RCSID() gets copied as well.
 If I simply edit one of the files and make changes, I can easily edit
 the __RCSID() as well.   There's nothing extra needed to support, this
 all just works.   Aside from when build.sh attempts to work out the
 build version (cvslatest and its equiv for hg or git I assume) which
 isn't something I need, nothing it does cares about the version control
 system in use, and after checking options etc, setting up for cross builds
 (also unneeded in this usage) all it does is run make.   Just running
 make by hand should always work.
 
   |  I didn't see the question posed anywhere yet either, so it's not
   |  surprising to me it hasn't been answered.
 
 Hmm, you're right, I intended to include that in my first reply, but it
 seems I side-tracked myself, and then forgot to actually include it.
 
   |  Since you keep stating fiat statements, I'll do that too: No, that
   |  doesn't need to "keep working".
 
 I think you'd find that most developers who work on the src/* tree
 much wouldn't agree with you - that's more or less equivalent to saying
 that all that has to work in pkgsrc is pbulk and simply doing "make"
 in one of the pkg src directories doesn't need to keep working.   Building
 all must work, but there's no need to be able to build selectively.
 Nonsense.
 
 Having said all that, between my last message and this one, I actually
 went (finally) and looked to see what the changes actually are, which I
 hadn't done before (and obviously neither had you, or your responses would
 have been quite different) - I was relying upon just what was in this PR
 to work out what was desired to happen.   It turns out that was not very
 precise.
 
 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).
 
 Given that, and assuming we can end up producing an identifier (or string)
 to replace $NetBSD$ (and perhaps some of the others, though those are
 generally less important) that identifies each file (for the __RCSID, and
 the line 1 (sometimes later) comment line identifier, all will be well.
 
 kre