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

[Anand J <anand.indukala@gmail.com>]

On Sun, Oct 9, 2016 at 3:04 AM, Eric Blake <eblake@redhat.com> 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 <eblake@redhat.com> 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
> meantime.
>
agree. Adding to the comments for future reference.

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