qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] typedefs: Put them back into alphabetical order


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] typedefs: Put them back into alphabetical order
Date: Thu, 19 Nov 2015 14:29:43 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 11/19/2015 06:10 AM, Daniel P. Berrange wrote:
> On Thu, Nov 19, 2015 at 01:03:39PM +0000, Dr. David Alan Gilbert wrote:
>> * Markus Armbruster (address@hidden) wrote:
>>> "Please keep this list in alphabetical order" has been more honoured
>>> in the breach than in the observance.  Clean up.

Whose alphabet? ...

>>>
>>> While there, drop a redundant struct declaration.
>>>
>>> Signed-off-by: Markus Armbruster <address@hidden>
>>

Reviewed-by: Eric Blake <address@hidden>

>> Hmph, it's only a year since I sorted this file.
>> At least one of these changes is from a misordering within one patch!
> 
> Which just goes to show that any such rules about sorting are
> not worth the hassle unless you also provide some make rule to
> validate them as part of 'make test'. It shouldn't be too
> hard to hook it up - a make rule that runs this:
> 
>    grep typedef include/qemu/typedefs.h > orig.txt
>    sort orig.txt > sorted.txt

...This would have to be 'LC_ALL=C sort orig.txt ...' to ensure that
difference in locale doesn't change the order (whether due to
case-insensitivity, or due to ignoring whitespace).  Picking on one of
the changes in the commit:

$ printf 'typedef struct PropertyInfo PropertyInfo;\ntypedef struct
Property Property;\n' | sort # LANG=en_US.UTF-8
typedef struct PropertyInfo PropertyInfo;
typedef struct Property Property;
$ printf 'typedef struct PropertyInfo PropertyInfo;\ntypedef struct
Property Property;\n' | LC_ALL=C sort
typedef struct Property Property;
typedef struct PropertyInfo PropertyInfo;


>    diff orig.txt sorted.txt > /dev/null
> 
> as part of 'make test' would suffice

Also, Markus probably noticed the problem because I have a pending patch
that will be adding QObject to the list, and my addition will conflict
since it falls next to the fixup for Range vs. QEMUTimerListGroup.
Whichever one goes in first gets to watch the other rebase :)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]