From: Ryan Anderson <ryan@michonline.com>
To: David Vrabel <dvrabel@arcom.com>,
Linus Torvalds <torvalds@osdl.org>,
Len Brown <len.brown@intel.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: Versioning of tree
Date: Tue, 26 Oct 2004 14:04:09 -0400 [thread overview]
Message-ID: <20041026180408.GI10638@michonline.com> (raw)
In-Reply-To: <20041026190815.GA8338@mars.ravnborg.org>
On Tue, Oct 26, 2004 at 09:08:15PM +0200, Sam Ravnborg wrote:
> On Tue, Oct 26, 2004 at 08:26:33AM -0400, Ryan Anderson wrote:
> > On Tue, Oct 26, 2004 at 12:49:02PM +0100, David Vrabel wrote:
> > > Ryan Anderson wrote:
> > > >
> > > >Well, here's a patch that adds -BKxxxxxxxx to LOCALVERSION when a
> > > >top-level BitKeeper tree is detected.
> > > >[...]
> > > > LOCALVERSION = $(subst $(space),, \
> > > > $(shell cat /dev/null $(localversion-files)) \
> > > >+ $(subst ",,$(localversion-bk)) \
> > >
> > > Surely there's no need for this? Can't the script spit out an
> > > appropriate localversion* file instead?
> >
> > It can, and yes, my first version used that method.
> >
> > Except it never worked. I was able to generate the file before
> > include/linux/version.h was rebuilt, but failed to get it picked up in
> > that. I'm not really sure why.
>
> The $(wildcard ...) function was executed before you created the file.
Right. I was unable to find a way to force the script to be run before
the $(wildcard) function was run - but, I don't claim to truly
understand what's going on in the Makefile.
> If we shall retreive the version from a SCM then as you already do
> must hide it in a script.
> I want the script only to be executed when we actually ask kbuild to
> build a kernel - so it has to be part of the prepare rule set.
By this, do you include targets such as *config?
The Debian tool used for generating Debian kernels determines the
version after doing a "make oldconfig", I believe, stores that away and
gets confused later when it doesn't match what it's actually building.
(Oh, and aside - it knows about localversion* and CONFIG_LOCALVERSION
for about 2-3 weeks, so a tweak to how the version is calculated
shouldn't be horrible to get picked up.)
> Furthermore I like to avoid a dependency on perl for a basic kernel.
I thought perl was already used somewhere intrinsically during a build.
> Can you retreive the version from bk using a simple shell script?
Sure. The major problem then is figuing out what to do with the key
that you get. My first inclination was to take a key like:
ryan@michonline.com[ryan]|ChangeSet|20041026060927|60419
and simply use a hash on it, then take a substring of the hash to get a
semi-random string that can be deterministically generated.
I used Perl simply because I know of a fairly well-distributed module
that provides that functionality (i.e, Digest::MD5, part of the
distribution of 5.6 and 5.8).
Obviously, something like md5sum could do the job with a temp file.
Since I *thought* there was already a dependency on Perl, I was avoiding
that.
I was planning on a followup version that would add a CONFIG variable,
i.e, CONFIG_LOCALVERSION_AUTO, that drove this whole additional step, and
at the same time, to work out a similar method to do this for CVS.
--
Ryan Anderson
sometimes Pug Majere
next prev parent reply other threads:[~2004-10-26 18:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-20 6:49 Benjamin Herrenschmidt
2004-10-20 7:22 ` Len Brown
2004-10-20 14:33 ` Linus Torvalds
2004-10-21 1:38 ` Benjamin Herrenschmidt
2004-10-21 15:33 ` Måns Rullgård
2004-10-21 15:48 ` Linus Torvalds
2004-10-21 16:49 ` Jeff Garzik
2004-10-21 17:10 ` Linus Torvalds
2004-10-21 23:03 ` kbuild (was Re: Versioning of tree) Jeff Garzik
2004-10-30 23:34 ` Sam Ravnborg
2004-10-25 23:47 ` Versioning of tree Ryan Anderson
2004-10-26 11:49 ` David Vrabel
2004-10-26 12:26 ` Ryan Anderson
2004-10-26 12:58 ` David Vrabel
2004-10-26 19:08 ` Sam Ravnborg
2004-10-26 18:04 ` Ryan Anderson [this message]
2004-10-26 19:11 ` Ian Campbell
2004-10-27 8:38 ` Ryan Anderson
2004-10-27 11:37 ` Sam Ravnborg
2004-10-20 8:22 ` Jeff Garzik
2004-10-20 8:39 ` Benjamin Herrenschmidt
2004-10-20 10:36 ` Måns Rullgård
2004-10-20 18:27 Chuck Ebbert
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=20041026180408.GI10638@michonline.com \
--to=ryan@michonline.com \
--cc=benh@kernel.crashing.org \
--cc=dvrabel@arcom.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome