[libvirt] [PATCH 2/2] src: More cleanup of some system headers already contained in internal.h

Erik Skultety eskultet at redhat.com
Thu Sep 20 06:13:18 UTC 2018


On Thu, Sep 20, 2018 at 08:04:24AM +0200, Michal Privoznik wrote:
> On 09/19/2018 05:50 PM, Erik Skultety wrote:
> > On Wed, Sep 19, 2018 at 05:42:18PM +0200, Michal Privoznik wrote:
> >> On 09/19/2018 12:22 PM, Erik Skultety wrote:
> >>> All of the ones being removed are pulled in by internal.h. The only
> >>> exception is sanlock which expects the application to include <stdint.h>
> >>> before sanlock's headers, because sanlock prototypes use fixed width
> >>> int, but they don't include stdint.h themselves, so we have to leave
> >>> that one in place.
> >>>
> >>> Signed-off-by: Erik Skultety <eskultet at redhat.com>
> >>> ---
> >>
> >> Is there an automated way to verify this? I don't expect anybody going
> >> one file after another just to see if this is correct.
> >
> > That would be madness. In fact what I did after sed'ing this was trying to
> > compile it until it passed.
> >
> >>
> >> I think the fact that this would pass travis/jenkins could be enough.
> >> But there has to be a better way.
> >
> > That's in fact what I did, I built the repo on ubuntu-18, centos-7, fedora-28,
> > rawhide, freebsd-11. I also verified with mingw and Clang.
> >
>
> Well, this sounds reasonable. What I am worried about is that some
> functions might require more than one header files (e.g. open(2)). And
> even though everything is working for me if I include only one of them,
> compilation might not work on say mingw because all three header files
> are required there.
>
> However, given that we improved jenkinks, I'd say lets rely on it in
> this case and merge these patches.

Thanks,
indeed, we can spot a problem pretty fast. I guess as an improvement, I could
put internal.h into every C module explicitly and make a syntax-check rule
similarly as we have for config.h, you know, to make things more explicit,
since now the internal.h gets to most of the modules transitively.

Erik




More information about the libvir-list mailing list