[Top][All Lists]

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

Re: [Qemu-trivial] [Qemu-devel] [PATCH] clean-up: removed duplicate #inc

From: Anand J
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] clean-up: removed duplicate #includes
Date: Sun, 9 Oct 2016 15:03:25 +0530

On Sun, Oct 9, 2016 at 3:04 AM, Eric Blake <address@hidden> wrote:
On 10/08/2016 06:32 AM, Anand J wrote:
> I have replied for the questions inline. Also I'll make changes to the
> patch as per the review and send the updated one.
> Thanks,
> Anand
> On Fri, Oct 7, 2016 at 8:01 PM, Eric Blake <address@hidden> wrote:
>> On 10/07/2016 03:46 AM, Anand J wrote:
>>> Some files contain multiple #includes of the same header file.
>>> Removed most of those unnecessary duplicate entries.
>> How did you find these? Is it a repeatable formula for rerunning a year
>> from now to find new culprits?  If so, listing it in the commit message
>> would be worthwhile.  Is it something we should add to
>> scripts/clean-includes?
> I executed the following bash script to get multiple occurrences of
> #includes and manually checked each and every file from the output.
> grep -r --exclude-dir=bin/ "#include" | sort | uniq -c | awk '{if ($1 > 1)
> print $2}'

Seems simple enough that we ought to make it part of the
scripts/clean-includes, rather than remembering to manually run it.
scripts/clean-includes does an in place modification of the duplicate entries in the files. 
There is no guarantee that my script with return all genuine duplicate entries. Some can be false positive as well.
Are you asking me to add this script in as a comment in scripts/clean-includes files? Like the one
for checking if all the files start with #include "osdep.h" ?

# for i in $(git ls-tree --name-only HEAD) ; do test -f $i && \
#   grep -E '^# *include' $i | head -1 | grep 'osdep.h' ; test $? != 0 && \
#   echo $i ; done

> But there are lot of noise in the output of this command. Most of the
> multiple #includes were not genuine issue. @Eric Do you want me to add this
> in the comment?

Yes - whatever we end up with (whether a manual script or a run of
scripts/clean-includes), documenting the process used makes it easier to
verify that you didn't miss anything, and for someone else to repeat the
process in another year when some mistakes have crept back in during the
agree. Adding to the comments for future reference.

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

reply via email to

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