lkml.org 
[lkml]   [2004]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Versioning of tree
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.173 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site