Re: [Xen-devel] Changeset / commit id not incorporated in build after switch to git

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Tuesday, February 26, 2013, 11:20:07 AM, you wrote:

> On Mon, 2013-02-25 at 23:00 +0000, Sander Eikelenboom wrote:
>> Hello Sander,

> Talking to yourself is a sign of something or other I think ;-)

primarily hitting the send button a bit before my thoughts actually ended :-p 
(at least i hope)


>> Monday, February 25, 2013, 11:28:53 PM, you wrote:
>> 
>> > Date: Mon, 25 Feb 2013 23:28:53 +0100
>> > From: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
>> > Organization: Eikelenboom IT services
>> > X-Priority: 3 (Normal)
>> > Message-ID: <1208255021.20130225232853@xxxxxxxxxxxxxx>
>> > To: xen-devel <xen-devel@xxxxxxxxxxxxx>
>> > Subject: Changeset / commit id not incorporated in build after switch to 
>> > git
>> > MIME-Version: 1.0
>> > Content-Type: text/plain; charset=us-ascii
>> > Content-Transfer-Encoding: 7bit
>> 
>> > Hi All,
>> 
>> > After the switching from mercurial to git, the changeset isn't 
>> > incorporated anymore in the build.
>> > This makes error reports possibly a bit less verbose (xl dmesg, serial 
>> > logs and xl info now omit the changeset (or commit) info)
>> 
>> > Git doesn't have the concept of changesets afaik and mercurial is, while 
>> > deprecated, still used as mirror.
>> 
>> > So what would be wise:
>> >    - just replace the changeset with the git commit sha-1 hash (always)
>> >    - use changeset when a mercurial tree is detected or the last git 
>> > commit sha-1 (and date ?) when a git tree is detected
>> >    - make a separate "commit" entry besides the changeset and leave one 
>> > undefined
>> 
>> > xen/Makefile currently has:
>> 
>> > # compile.h contains dynamic build info. Rebuilt on every 'make' 
>> > invocation.
>> > include/xen/compile.h: include/xen/compile.h.in .banner
>> >         @sed -e 's/@@date@@/$(shell LC_ALL=C date)/g' \
>> >             -e 's/@@time@@/$(shell LC_ALL=C date +%T)/g' \
>> >             -e 's/@@whoami@@/$(XEN_WHOAMI)/g' \
>> >             -e 's/@@domain@@/$(XEN_DOMAIN)/g' \
>> >             -e 's/@@hostname@@/$(shell hostname)/g' \
>> >             -e 's!@@compiler@@!$(shell $(CC) $(CFLAGS) --version 2>&1 | 
>> > head -1)!g' \
>> >             -e 's/@@version@@/$(XEN_VERSION)/g' \
>> >             -e 's/@@subversion@@/$(XEN_SUBVERSION)/g' \
>> >             -e 's/@@extraversion@@/$(XEN_EXTRAVERSION)/g' \
>> >             -e 's!@@changeset@@!$(shell ((hg parents --template 
>> > "{date|date} {rev}:{node|short}" >/dev/null && hg parents --template 
>> > "{date|date} {rev}:{node|short}") || echo "unavailable") 2>/dev/null)!g' \
>> >             < include/xen/compile.h.in > $@.new
>> >         @grep \" .banner >> $@.new
>> >         @grep -v \" .banner
>> >         @mv -f $@.new $@
>> 
>> > --
>> > Sander
>> 
>> 
>> 
>> Perhaps use about the same as linux has in scripts/setlocalversion ?

> This is what I was going to suggest. Actually, I had it in mind we
> already did something like!

> Anyway, I think including whatever information the VCS we are building
> from supplied is the right answer and the way Linux does it seems useful
> and appropriate (e.g. using the tag name, appending -dirty etc).

> If we can also extend that to do something sensible in the tarball case
> then even better!

Not much info to get form a extracted tarball i'm afraid ?
Or one should include some extra versioning in the tarball itself and in that 
case you don't know if its "dirty" or not, just a "based on tarball with 
changeset/commit"

Since in that case it will describe something more/else than a mecurial 
changeset,
question is should the name "changeset" also be replaced by some more general 
naming ?



> Ian.




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel