From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: does a normal OE kernel build negate the ability to generate a local version string?
Date: Fri, 8 Apr 2016 09:57:02 -0400 (EDT) [thread overview]
Message-ID: <alpine.LFD.2.20.1604080942280.11776@localhost.localdomain> (raw)
i was just playing with wind river linux 8 and trying to figure out
why i couldn't generate a local version string that contained the git
commit ID, so i zipped over to oe-core to see how it was done there,
and it seems to be the same way, so can someone clarify that my
understanding here is correct?
normally, if i want to add the git commit ID ("-gxxxxxxxx") to the
kernel version string so it's available via "uname", i'm used to
selecting the kernel config option CONFIG_LOCALVERSION_AUTO, which
uses:
$ git rev-parse --verify HEAD
to extract the first 8 characters of the commit ID. so i selected that
option, but wasn't getting that string.
poking around further, i saw this in scripts/setlocalversion:
scm_version()
{
local short
short=false
cd "$srctree"
if test -e .scmversion; then
cat .scmversion
return
fi
... snip ...
so if the file ".scmversion" exists, its contents are used instead.
now *i* never set that file, but lo and behold, in the kernel source
tree, there it was, empty, which explains why i wasn't getting any
local version string.
and where did that empty .scmversion file come from? i see this in
kernel.bbclass:
kernel_do_configure() {
# fixes extra + in /lib/modules/2.6.37+
# $ scripts/setlocalversion . => +
# $ make kernelversion => 2.6.37
# $ make kernelrelease => 2.6.37+
touch ${B}/.scmversion ${S}/.scmversion <---- there
... snip ...
which clearly appears to touch that empty file. is that deliberate? is
this an explicit decision by this bbclass file to prevent people from
generating that local version string? am i reading all this correctly?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
next reply other threads:[~2016-04-08 13:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-08 13:57 Robert P. J. Day [this message]
2016-04-08 14:07 ` does a normal OE kernel build negate the ability to generate a local version string? Martin Jansa
2016-04-11 10:31 ` Robert P. J. Day
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.2.20.1604080942280.11776@localhost.localdomain \
--to=rpjday@crashcourse.ca \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.