Hi Linus !
After you tag a "release" tree in bk, could you bump the version number
right away, with eventually some junk in EXTRAVERSION like "-devel" ?
It's quite painful to have a module dir name clash between the "clean"
final tree and whatever dev stuff we are testing out of bk ... it's fine
once you go to -rc1, but in the meantime, it's really annoying.
Cheers,
Ben.
On Wed, 2004-10-20 at 02:49, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> After you tag a "release" tree in bk, could you bump the version
> number right away, with eventually some junk in EXTRAVERSION like
> "-devel" ?
I'd find this to be really helpful too. There has been this period
between, say, 2.6.9 and 2.6.10-whatever where my build/install scripts
scribble over my "reference" kernels.
thanks,
-Len
On Wed, 2004-10-20 at 18:22, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > Hi Linus !
> >
> > After you tag a "release" tree in bk, could you bump the version number
> > right away, with eventually some junk in EXTRAVERSION like "-devel" ?
> >
> > It's quite painful to have a module dir name clash between the "clean"
> > final tree and whatever dev stuff we are testing out of bk ... it's fine
> > once you go to -rc1, but in the meantime, it's really annoying.
>
> echo "-bk" > localversion
> make
>
> You can do it just as easily as anyone else :)
Of course I can, and of course I keep forgetting... :) And a bunch of ppl
are apparently having the same problem :) Not even counting a guy this
morning reporting me of "problems with 2.6.9" while he was actually using
the bk top of tree from yesterday night...
But well, it's up to Linus :) I just though it would be convenient ...
Ben.
Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> After you tag a "release" tree in bk, could you bump the version number
> right away, with eventually some junk in EXTRAVERSION like "-devel" ?
>
> It's quite painful to have a module dir name clash between the "clean"
> final tree and whatever dev stuff we are testing out of bk ... it's fine
> once you go to -rc1, but in the meantime, it's really annoying.
echo "-bk" > localversion
make
You can do it just as easily as anyone else :)
Jeff
Benjamin Herrenschmidt <[email protected]> writes:
> Hi Linus !
>
> After you tag a "release" tree in bk, could you bump the version number
> right away, with eventually some junk in EXTRAVERSION like "-devel" ?
>
> It's quite painful to have a module dir name clash between the "clean"
> final tree and whatever dev stuff we are testing out of bk ... it's fine
> once you go to -rc1, but in the meantime, it's really annoying.
I've been thinking of the possibility to automate something like that
using a bk trigger.
--
M?ns Rullg?rd
[email protected]
On Wed, 2004-10-20 at 02:49, Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> After you tag a "release" tree in bk, could you bump the version
> number right away, with eventually some junk in EXTRAVERSION like
> "-devel" ?
How about 2.6.10-pre0 ??? A single tagged changeset that does this
should work OK, right?
--Chuck Ebbert 20-Oct-04 14:26:26
On Thu, 2004-10-21 at 00:33, Linus Torvalds wrote:
> Personally, I much rather go the way we have gone, because I don't care
> about module versioning nearly as much as I care about bug-report
> versioning. And if I hear about a bug with 2.6.10-rc1, I want to know that
> it really is at _least_ 2.6.10-rc1, if you see what I mean..
I have the same problem with reports. I'm not talking about -rc*, that
is fine, I know that a report against rc-* means and most user will usually
tell me rc*-bk* so that's ok.
The problem is just with this intermediate state between 2.6.N "final" and
whatever gets next until we go to -rc. The fact that it has the exact same
version as 2.6.N final means that I get confusing reports (and, but I know
you don't care about modules, but it's simply impossible to have both
the "final" modules and the "current top of tree" modules installed at the
same time, which _is_ painful).
When I was still doing my "pmac" tree, what I would do was to put -pre0
in the EXTRAVERSION after a release until I got to -preX or -rcX...
Anyway, it's your call.
Ben.
On Wed, 20 Oct 2004, Len Brown wrote:
>
> On Wed, 2004-10-20 at 02:49, Benjamin Herrenschmidt wrote:
> >
> > After you tag a "release" tree in bk, could you bump the version
> > number right away, with eventually some junk in EXTRAVERSION like
> > "-devel" ?
>
> I'd find this to be really helpful too. There has been this period
> between, say, 2.6.9 and 2.6.10-whatever where my build/install scripts
> scribble over my "reference" kernels.
Personally, I much rather go the way we have gone, because I don't care
about module versioning nearly as much as I care about bug-report
versioning. And if I hear about a bug with 2.6.10-rc1, I want to know that
it really is at _least_ 2.6.10-rc1, if you see what I mean..
Now, personally, I'd actually like to know the exact top-of-tree
changeset, so I've considered having something that saves that one away,
but then we'd need to do something about non-BK users (make the nightly
snapshots squirrell it away somewhere too). That would solve both the
module versioning _and_ the bug-report issue.
So if somebody comes up with a build script that generates that kind of
extra-version automatically, I'm more receptive. But I don't want to muck
with the version manually in a way that I think is the wrong way around..
Linus
On Thu, 21 Oct 2004, M?ns Rullg?rd wrote:
>
> Would it work to somewhere in the Makefile check for the existence of
> a BitKeeper directory, and if it exists run bk with the appropriate
> arguments and append something to EXTRAVERSION? I'm not quite sure
> which information is the best to add, though.
That's what I had in mind. But it should also check if the top-of-tree is
already tagged, and not do anything for that. And it should also hopefully
have a CVS/Subversion equivalent, just so that people don't feel left out.
I would _suggest_ just exporting the whole top-of-tree tag to some
/sys/kernel/version file (for full bug-reports), but in addition also
maybe have a small hash of it (just a few characters of noise) in "uname",
to make module versioning work.
So "uname -r" might print out "2.6.9-a$Uv", but then a
cat /sys/kernel/version/*
would print out something like
"kernel" file:
v2.6.9-a$Uv
"bk-key" file:
[email protected]|ChangeSet|20041021004441|21737
"date" file:
Wed Oct 20 22:29:23 PDT 2004
or something (one value per file as usual)
Linus
Linus Torvalds wrote:
> Now, personally, I'd actually like to know the exact top-of-tree
> changeset, so I've considered having something that saves that one away,
> but then we'd need to do something about non-BK users (make the nightly
> snapshots squirrell it away somewhere too). That would solve both the
> module versioning _and_ the bug-report issue.
The nightly snapshots have been exporting this info since Day One, based
on your request ;-)
<snapshot>.key contains this info, e.g.
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.9-bk1.key
is T.O.T. for
http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.9-bk1.bz2
On Thu, 21 Oct 2004, Jeff Garzik wrote:
>
> The nightly snapshots have been exporting this info since Day One, based
> on your request ;-)
Yes. But that doesn't help the people who actually use the native BK trees
themselves, or the people who use the CVS exports. That was what Ben was
complaining about.
We already have the concept of "localversion*" files that get appended to
the build. So the only thing that would be needed is some Makefile magic
to create a "localversion-bk-version" file if the top-of-tree isn't
tagged, and we'd get some unique ID for native BK users too.
Linus
Linus Torvalds <[email protected]> writes:
> On Wed, 20 Oct 2004, Len Brown wrote:
>>
>> On Wed, 2004-10-20 at 02:49, Benjamin Herrenschmidt wrote:
>> >
>> > After you tag a "release" tree in bk, could you bump the version
>> > number right away, with eventually some junk in EXTRAVERSION like
>> > "-devel" ?
>>
>> I'd find this to be really helpful too. There has been this period
>> between, say, 2.6.9 and 2.6.10-whatever where my build/install scripts
>> scribble over my "reference" kernels.
>
> Personally, I much rather go the way we have gone, because I don't care
> about module versioning nearly as much as I care about bug-report
> versioning. And if I hear about a bug with 2.6.10-rc1, I want to know that
> it really is at _least_ 2.6.10-rc1, if you see what I mean..
>
> Now, personally, I'd actually like to know the exact top-of-tree
> changeset, so I've considered having something that saves that one away,
> but then we'd need to do something about non-BK users (make the nightly
> snapshots squirrell it away somewhere too). That would solve both the
> module versioning _and_ the bug-report issue.
>
> So if somebody comes up with a build script that generates that kind of
> extra-version automatically, I'm more receptive. But I don't want to muck
> with the version manually in a way that I think is the wrong way around..
Would it work to somewhere in the Makefile check for the existence of
a BitKeeper directory, and if it exists run bk with the appropriate
arguments and append something to EXTRAVERSION? I'm not quite sure
which information is the best to add, though.
--
M?ns Rullg?rd
[email protected]
Linus Torvalds wrote:
> We already have the concept of "localversion*" files that get appended to
> the build.[...]
Just to tangent a bit... I've been meaning to throw out a public kudos
to Sam, Kai, Roman and the other kbuild/kconfig hackers. The 2.6 kbuild
and kconfig system is a _huge_ improvement over 2.4.x.
These days I use
echo "-sataN" > localversion
heavily, and it's been quite helpful. The separation of src/obj
directories, the default verbosity level, 'make allyesconfig', and the
elimination of recursive Makefile invocations are just some of the
things that stick out as positive improvements that impact me on a daily
basis.
Thanks guys!
Jeff
On Wed, Oct 20, 2004 at 07:33:47AM -0700, Linus Torvalds wrote:
> Personally, I much rather go the way we have gone, because I don't care
> about module versioning nearly as much as I care about bug-report
> versioning. And if I hear about a bug with 2.6.10-rc1, I want to know that
> it really is at _least_ 2.6.10-rc1, if you see what I mean..
Well, here's a patch that adds -BKxxxxxxxx to LOCALVERSION when a
top-level BitKeeper tree is detected.
Signed-off-by: Ryan Anderson <[email protected]>
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2004-10-25 19:45:55 -04:00
+++ b/Makefile 2004-10-25 19:45:55 -04:00
@@ -149,6 +149,12 @@
# careful not to include files twice if building in the source
# directory. LOCALVERSION from the command line override all of this
+ifeq ($(shell ls -d $(srctree)/BitKeeper 2>/dev/null),$(srctree)/BitKeeper)
+localversion-bk := $(shell perl $(srctree)/scripts/setlocalversion $(srctree) $(objtree))
+else
+localversion-bk :=
+endif
+
ifeq ($(objtree),$(srctree))
localversion-files := $(wildcard $(srctree)/localversion*)
else
@@ -157,6 +163,7 @@
LOCALVERSION = $(subst $(space),, \
$(shell cat /dev/null $(localversion-files)) \
+ $(subst ",,$(localversion-bk)) \
$(subst ",,$(CONFIG_LOCALVERSION)))
KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(LOCALVERSION)
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion 2004-10-25 19:45:55 -04:00
@@ -0,0 +1,62 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <[email protected]> GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 2) {
+ print <<EOT;
+Usage: setlocalversion <srctree> <objtree>
+EOT
+ exit(1);
+}
+
+my $debug = 0;
+
+my ($srctree,$objtree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches)
+# We currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+
+#ryan@mythryan2 ~/dev/linux/local$ T=`bk changes -r+ -k`
+#ryan@mythryan2 ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset;
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ printf("ChangeSet Key = '%s'\nTAG = '%s'\n", $changeset, $tag) if ($debug > 0);
+
+ if (length($tag) == 0) {
+ # We do not have a tag at the Top of Tree, so we need to generate a localversion file
+ # We'll use the given $changeset as input into this.
+ my $localversion = Digest::MD5::md5_hex($changeset);
+ $localversion = substr($localversion,0,8);
+
+ printf("localversion = '%s'\n",$localversion) if ($debug > 0);
+
+ push @LOCALVERSIONS, "BK" . $localversion;
+
+ }
+}
+
+
+if ( -d "BitKeeper" ) {
+ my $bk = `which bk`;
+ chomp $bk;
+ if (length($bk) != 0) {
+ do_bk_checks();
+ }
+}
+
+printf "-%s\n", join("-",@LOCALVERSIONS) if (scalar @LOCALVERSIONS > 0);
--
Ryan Anderson
sometimes Pug Majere
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?
Tools like Debian's make-kpkg have to work out the kernel version (for
use in the package name etc.) and it would be preferable if the method
for generating the version didn't change too often.
David Vrabel
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
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.
For what it's worth, "make deb-pkg" picks up the version correctly using
this method:
dpkg-deb: building package `linux-2.6.10-rc1-bkd581e3d1' in
`../linux-2.6.10-rc1-bkd581e3d1_2.6.10-rc1-BKd581e3d1_i386.deb'.
> Tools like Debian's make-kpkg have to work out the kernel version (for
> use in the package name etc.) and it would be preferable if the method
> for generating the version didn't change too often.
Well, I didn't think make-kpkg was doing anything horribly unexpected,
so I didn't to test that. I'll do a test run now to see what happens,
though.
--
Ryan Anderson
sometimes Pug Majere
Ryan Anderson wrote:
>
> Well, I didn't think make-kpkg was doing anything horribly unexpected,
> so I didn't to test that. I'll do a test run now to see what happens,
> though.
I think there might be problems when you use make-kpkg's
--append-to-version option. make-kpkg works out what the original
version string should be and then tacks the extra bit on before
overriding the original version.
More an argument for fixing make-kpkg to be less stupid I suppose.
Of course, the tool I'm using was derived from make-kpkg some time ago
and could be broken and the proper (and newer) make-kpkg works fine.
David Vrabel
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
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.
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.
Furthermore I like to avoid a dependency on perl for a basic kernel.
Can you retreive the version from bk using a simple shell script?
Sam
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:
[email protected][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
On Tue, Oct 26, 2004 at 02:04:09PM -0400, Ryan Anderson wrote:
> 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.
Isn't there already CONFIG_LOCALVERSION? If you have to set _AUTO in
your config then you may as well just bash -bk into CONFIG_LOCALVERSION.
Ian.
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:
> > > 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.
Can you explain why?
i.e, if I do this:
localversion-bk := $(shell echo x > localversion-bk)
localversion-files := $(wildcard localversion*)
I seem to get "localversion-bk" in my localversion-files variable, but
when I do something similar in the master Makefile, it doesn't seem to
get picked up correctly.
i.e, this doesn't work the same way, for some reason:
localversion-test := $(shell echo x > localversion)
ifeq ($(objtree),$(srctree))
localversion-files := $(wildcard $(srctree)/localversion*)
else
localversion-files := $(wildcard $(objtree)/localversion* $(srctree)/localversion*)
endif
This is all mostly off-topic, however, as it's irrelevant to what you
asked later.
> 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.
As part of the prepare ruleset, should I simply add a prepare3 (and hook
it in appropriately), or do you mean, just have it in the same section
> Furthermore I like to avoid a dependency on perl for a basic kernel.
> Can you retreive the version from bk using a simple shell script?
After thinking about it - yes (I instead add a dependency on md5sum, so,
I guess, take your pick as to which is more likely to be a problem.)
The patch below has both the Perl and shell script in it, as well as the
added config option to disable this feature.
Signed-off-by: Ryan Anderson <[email protected]>
diff -Nru a/Makefile b/Makefile
--- a/Makefile 2004-10-27 04:33:05 -04:00
+++ b/Makefile 2004-10-27 04:33:05 -04:00
@@ -513,6 +513,24 @@
#export INSTALL_PATH=/boot
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any sort,
+# or if is a pure development tree.
+# A 'release tree' is any tree with a BitKeeper TAG associated with it.
+# The primary goal of this is to make it safe for a native BitKeeper user to
+# build a release tree (i.e, 2.6.9) and also to continue developing against the
+# current Linus tree, without having the Linus tree overwrite the 2.6.9 tree
+# when installed.
+#
+# (In the future, CVS and SVN support will be added as well.)
+
+ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
+ ifeq ($(shell ls -d $(srctree)/BitKeeper 2>/dev/null),$(srctree)/BitKeeper)
+ localversion-bk := $(shell $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+ LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
+ endif
+endif
+
#
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
# relocations required by build roots. This is not defined in the
diff -Nru a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig 2004-10-27 04:33:05 -04:00
+++ b/init/Kconfig 2004-10-27 04:33:05 -04:00
@@ -69,6 +69,18 @@
object and source tree, in that order. Your total string can
be a maximum of 64 characters.
+config LOCALVERSION_AUTO
+ bool "Automatically append version information to the version string"
+ default y
+ help
+ This will try to automatically determine if the current tree is a
+ release tree by looking for BitKeeper tags that belong to the
+ current top of tree revision.
+ A string of the format -BKxxxxxxxx will be added to the
+ localversion. The string generated by this will be appended
+ after any matching localversion* files, and after the
+ value set in CONFIG_LOCALVERSION
+
config SWAP
bool "Support for paging of anonymous memory (swap)"
depends on MMU
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion 2004-10-27 04:33:05 -04:00
@@ -0,0 +1,62 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <[email protected]> GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 2) {
+ print <<EOT;
+Usage: setlocalversion <srctree> <objtree>
+EOT
+ exit(1);
+}
+
+my $debug = 0;
+
+my ($srctree,$objtree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches)
+# We currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+
+#ryan@mythryan2 ~/dev/linux/local$ T=`bk changes -r+ -k`
+#ryan@mythryan2 ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
+
+sub do_bk_checks {
+ chdir($srctree);
+ my $changeset = `bk changes -r+ -k`;
+ chomp $changeset;
+ my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+ printf("ChangeSet Key = '%s'\nTAG = '%s'\n", $changeset, $tag) if ($debug > 0);
+
+ if (length($tag) == 0) {
+ # We do not have a tag at the Top of Tree, so we need to generate a localversion file
+ # We'll use the given $changeset as input into this.
+ my $localversion = Digest::MD5::md5_hex($changeset);
+ $localversion = substr($localversion,0,8);
+
+ printf("localversion = '%s'\n",$localversion) if ($debug > 0);
+
+ push @LOCALVERSIONS, "BK" . $localversion;
+
+ }
+}
+
+
+if ( -d "BitKeeper" ) {
+ my $bk = `which bk`;
+ chomp $bk;
+ if (length($bk) != 0) {
+ do_bk_checks();
+ }
+}
+
+printf "-%s\n", join("-",@LOCALVERSIONS) if (scalar @LOCALVERSIONS > 0);
diff -Nru a/scripts/setlocalversion.sh b/scripts/setlocalversion.sh
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion.sh 2004-10-27 04:33:05 -04:00
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+BK=`which bk`
+
+srctree=$1
+objtree=$2
+
+if [ "$BK" == "" ];
+then
+ echo "scripts/setlocalversion.sh: Failed to find BK, not appending a -BK* version" >&2
+ exit 0
+fi
+
+cd $srctree
+changeset=`$BK changes -r+ -k`
+tag=`$BK prs -h -d':TAG:' -r'$changeset'`
+if [ "$tag" == "" ]; then
+ echo -n $changeset | md5sum | awk '{printf "-BK%s",substr($1,1,8)}'
+fi
> 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:
>> > > 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.
>
> Can you explain why?
GNU make distingush between ":=" and "=".
An assignment made using ":=" is done immediatly.
So when make first encounter ":=" is will execute the $(wildcard ...)
function, long
before you create the localversion-bk file.
If instead "=" is used the evaluation will be deferred until you actually
dereference the variable - so here the localversion-bk fiel may well be
created.
>
>> 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.
>
> As part of the prepare ruleset, should I simply add a prepare3 (and hook
> it in appropriately), or do you mean, just have it in the same section
The prepare part is more or less made to have full control on order of
the rules - so a make -j 50 goes well.
So just hooking it under prepare1 should do the trick.
>
> The patch below has both the Perl and shell script in it, as well as the
> added config option to disable this feature.
Will take a look when I'm on my Linux box.
Sam
On Thu, Oct 21, 2004 at 07:03:16PM -0400, Jeff Garzik wrote:
> Linus Torvalds wrote:
> >We already have the concept of "localversion*" files that get appended to
> >the build.[...]
>
>
> Just to tangent a bit... I've been meaning to throw out a public kudos
> to Sam, Kai, Roman and the other kbuild/kconfig hackers. The 2.6 kbuild
> and kconfig system is a _huge_ improvement over 2.4.x.
Thanks :-)
Kai and Roman have taken the big steps here!
>
> These days I use
> echo "-sataN" > localversion
> heavily, and it's been quite helpful. The separation of src/obj
> directories, the default verbosity level, 'make allyesconfig', and the
> elimination of recursive Makefile invocations are just some of the
> things that stick out as positive improvements that impact me on a daily
> basis.
The recursive Makefile invocations are still present. But just
working better than before.
I would like to write a small parser to generate one Makefile
for the kernel stuff but dunno when I will find time for it.
Main driver would be to increase speed when building a single
file. But it will also simplify building modules avoiding
the synchronization point we have before entering modpost stage.
Sam