(or svnliteversion) in the current lookup path is not what
was used to check out the tree. If an incompatible version
is used, the svn revision number is not reported in uname(1).
Run ${svnversion} on newvers.sh itself when evaluating if the
svn(1) in use is compatible with the tree. Fallback to an
empty ${svnversion} if necessary.
With this change, svnliteversion from base is only used
if no compatible svnversion is found, so with this change,
the version of svn(1) from the ports tree is evaluated first.
Requested by: many
MFC after: 3 days
X-MFC-To: stable/9, releng/9.2 only
the tree version, for example if the tree is checked out with an
outdated svn from ports, but the base system svnlite is built.
Approved by: kib (mentor)
This time it is for a git mirror that stores svn revisions as
git notes, e.g. https://github.com/freebsd/freebsd
MFC after: 10 days
Sponsored by: HybridCluster
system has svnliteversion.
- If svnliteversion is not found, look for svnversion in /usr/bin
and /usr/local/bin, since svnlite can be installed as svn if
WITH_SVN is set.[1]
- Remove /bin from binary search paths.[1]
Discussed with: kib [1]
MFC after: 3 days
Approved by: kib (mentor)
And provide kernel compiler version as a sysctl as well.
This is useful while we have gcc and clang cohabitation.
This could be even more useful when we have support
for external toolchains.
In cooperation with: mjg
MFC after: 13 days
it no longer exists). Instead, run svnversion if we can find the binary
and test that the output looks like a version string.
Reviewed by: discussion on -current@
Tested by: rodrigc for non-svn case (thanks!)
or some variation in the path, the new version assumes that $0 is
newvers.sh path, and that dirname $0/.. is the same as $S aka $SYSDIR.
It also removes knowledge of ${MACHINE} and ${MACHINE_ARCH}, which is
also good.
# I've had this in my tree for about 6 months now, which is why I
# didn't notice that I broke it in r209510 and that was fixed in
# r212954. This should finally resolve the issues people had with
# r204824 as well as address the issues that motivated r204824.
Find the most recently merged svn revision, too. If we get a svn revision
that matches HEAD use rXXX=GIT otherwise use rXXX+GIT.
Submitted by: avg
MFC after: 3 days
X-MFC: not stable/8 before 8.0
corresponding svn version if this is a git-svn clone'ed repo.
This prefers svn version information over git in case a working
directory has both .svn and .git directories.
MFC after: 3 days
X-MFC: not stable/8 before 8.0
during the kernel build process, the other places that call the script
do not make use of that information. So restrict execution of the
svnversion-related code to the kernel build context.
src/sys and not the entire src/ tree.
An earlier solution by peter had been comitted in r183528 and backed out
in r183566 due to problems with newvers.sh also called from other places
during world build. With the extra test this survived a make universe.
SRCDIR is seeded from `pwd` which not only means src/sys/ but
also src/include/ (and possibly src/usr.sbin/amd/include/ ?).
Trying to build world resulted in
===> include (includes)
cd /usr/src/include; make buildincludes; make installincludes
creating osreldate.h from newvers.sh
cd: can't cd to /usr/src/include/sys
*** Error code 2
as there is apparently no src/include/sys.
There are multiple possible solutions ranging from seeding SRCDIR from
the environment to adding more substitution patterns.
Reported by: sam, bz
Proper solution to be implemented and tested by: peter
newvers.sh is run pwd is actually the obj directory, so "../../.svn"
doesn't exist and the test always fails. The second is that buildkernel
is executed with a restrictive PATH, so unless you have svnversion in
/bin or /usr/bin it can't run.
Fix this by looking for svnversion in /bin, /usr/bin, and /usr/local/bin
in that order. If found, store the location and derive the value of the
source directory. Then run svnversion in the appropriate directory.
There is one possible refinement which would be to add a test for
LOCALBASE!=/usr/local if we don't find svnversion the first time, but
IMO that's not necessary at this time.
128 bytes, 256 bytes, and 32 bytes respectively. This makes it much
easier to identify when two kernels are identical apart from a version
number bump (as often happens on security branches).
Discussed on: freebsd-arch, in May 2005
and stop trying to play cute games so that sccs[] shares space with
version[].
Reported by: Jilles Tjoelker jilles at stack dot nl
Discussed with: bde, "R. Imura" imura at ryu16 dot org
Idea from: NetBSD (via bde)
Approved by: re (scottl)
MFC after: 1 week
This is necessary so source upgrades use the correct binary.
MFC after: 3 days
For the record: Problem spotted by Scott Long, who mentioned
that source upgrades from 4.7 to recent 5.x and 6.0 are broken.
Detailed analysis shows that 4.7 has a broken make(1) binary.
A breakage was fixed in RELENG_4 in make/main.c,v 1.35.2.7 by
imp@, though the commit log erroneously stated "MFC 1.68"
while in fact it should have been spelled as "MFC 1.67".
