newvers.sh request

Milan Obuch freebsd-hackers at dino.sk
Thu Apr 8 07:25:31 UTC 2021


Hi,

in old svn days, uname output reflected svn revision number. We had
svnlite in base system (if not set WITHOUT_SVN) and everything was done
automagically when doing buildkernel process.

Now, this is gone. Support for various revision string generation is
built in sys/conf/newvers.sh script. When source tree is being tracket
with git (recently gitup support is added), box where kernel is being
built needs git installed (or gitup as an alternative) to be able to
include this information in version string.

For my use case, this is not practical. I am using git to track sources
(or I am learning how to do it, first steps are done but still, it is
different and I am figuring new features as I am trying), but I'd
strongly prefer to use one box with larger disk capacity to hold all
sources, mount needed worktree via nfs on box running buildkernel
process, where I have minimal install, sometimes no port at all.
Note: only worktree, not a full repository, so even having git
installed would not help.

Looking in newvers.sh script I found gitup was added and this inspired
me to add just one more method covering my needs for such a distributed
or detached build. Gitup loads its revision string from file
.gituprevision, which is created when doing gitup src (exact invocation
not relevant here). This file is just included verbatim in version
string... so I hacked together similar thing:

--- newvers.sh.orig	2021-04-08 07:35:02.506801000 +0200
+++ newvers.sh	2021-04-08 08:08:32.100985000 +0200
@@ -230,6 +230,11 @@
 	done
 fi
 
+if findvcs .drevision; then
+	drevision="${VCSTOP}/.drevision"
+	echo "drevision ${drevision}" > ${VCSTOP}/.drevision-check
+fi
+
 if [ -n "$svnversion" ] ; then
 	svn=$(cd ${SYSDIR} && $svnversion 2>/dev/null)
 	case "$svn" in
@@ -275,12 +280,16 @@
 	fi
 fi
 
+if [ -n "$drevision" ] ; then
+	raw=" $(cat $drevision)"
+fi
+
 [ ${include_metadata} = "if-modified" -a ${modified} = "yes" ] && include_metadata=yes
 if [ ${include_metadata} != "yes" ]; then
-	VERINFO="${VERSION}${svn}${git}${hg} ${i}"
+	VERINFO="${VERSION}${svn}${git}${hg}${raw} ${i}"
 	VERSTR="${VERINFO}\\n"
 else
-	VERINFO="${VERSION} #${v}${svn}${git}${hg}: ${t}"
+	VERINFO="${VERSION} #${v}${svn}${git}${hg}${raw}: ${t}"
 	VERSTR="${VERINFO}\\n    ${u}@${h}:${d}\\n"
 fi

just using .drevision file for that purpose in order to explicitly
signal usage of different mechanism for revision string generation.
Variable names used are arbitrary. It is hard to invent something new,
nice and meaningfull :)

Usage is then

- git fetch to update repository
- git checkout to (new) worktree as needed, altering files as needed,
  adding patches as needed etc. for intended test
- run some script generating .drevision file (site dependent, it could
  be based on how git hash et al. is used to generate revision string
  in order to remain compatible with the rest of the world)
- mount worktree on a box where buildkernel is intended to run
- run make buildkernel as usual

I did this experiment on older 13-CURRENT tree, but idea could be used
on newer tree as well.

For curious: I am hacking on Zynq kernel and modules, there are
generally not much resources, storage on SD card can wear fast, my
setup allows me to minimize some bad side effects by reduced number of
writes using nfs for large storage requirements. Also, editing is done
on another box, only build process runs directly on Zynq board.

Regards,
Milan


More information about the freebsd-hackers mailing list