Re: [PATCH]: Always use KVM_VERSION to build version number

[Avi Kivity <avi@redhat.com>]

On 08/07/2009 03:31 PM, Chris Lalancette wrote:
> Avi,
>       Trying to use libvirt with development snapshots of qemu-kvm is a bit
> problematic.  The trouble is that for all development snapshots, the value that
> gets placed into this string:
>
> QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008
>
> Is always kvm-devel.  That means we can't tell if this is a kvm development
> snapshot built yesterday, or 6 months ago, which means that in turn we can't
> tell what features are available.  While we can always tell people building
> their own qemu to force it by echoing a value into KVM_VERSION, it would be much
> better if this were done by default.  Something like kvm-88-devel, which would
> signify that this the development happening after kvm-88, leading towards
> kvm-89.  Would you accept something like the patch below, which would require
> you to edit the KVM_VERSION file twice during a release (once right before the
> release, to change it to kvm-89, and once right after the release to change it
> back to kvm-89-devel)?
>
>    

This is problematic in two ways.  One is that I am basically guaranteed 
to forget to edit the file (which is why the release scripts generate 
the name based on the tag).

On fix is to use git describe --match to find out what's the closest 
release.  But this is still quite bad as it doesn't account for branches 
and forks.

How about adding 'qemu -describe-features' which will output, one line 
per feature, what's supported (and limits where applicable)?  I 
understand libvirt already does this for some features using -help; this 
is simply a formalization of that hack.

-- 
error compiling committee.c: too many arguments to function