On 11/15/2016 04:18 AM, Stefan Hajnoczi wrote: > On Tue, Nov 15, 2016 at 10:04:05AM +0800, Fam Zheng wrote: >> On Mon, 11/14 13:06, Eric Blake wrote: >>> So I guess you have to determine if libqnio is something that should >>> compile completely independent from qemu, or whether it is so closely >>> tied to the rest of qemu that it should follow qemu conventions. >> >> The question is on include directives in block/vxhs.c, not libnqio library >> header, so qemu conventions apply. > > Eric: The libqnio library header is not copied into the QEMU source > tree. It is an external library dependency like libnfs or libglfs. > > Fam, Markus: Unfortunately neither the clean-includes script nor its > patch series cover letter explains *why* osdep.h should be included > before system headers.
For the same reason that <config.h> should be included first before system headers in an autoconf'd project. Many platforms ship (semi-)broken system headers, where configure detects AND works around the problems, but only if the workaround CONSISTENTLY happens before any system header is included. It is a LOT harder to track down compilation or link or even subtle runtime failures if you don't consistently use your workaround all the time, such that some .c files got the workaround but others did not. > The libqnio header is self-contained (i.e. you can #include it and it > has no dependencies) and only used by vxhs.c. Why is it a good idea to > include qemu/osdep.h first? > > Seems like a bad idea to me because it masks missing dependencies in the > libqnio header. If the libqnio header is completely independent, then it should not be part of the qemu source tree (with "" inclusion), but should instead be externally included (with <> inclusion), just like any other third-party library we link against. But even then, we STILL want our osdep.h to occur before ANY third-party library, so that we have a CONSISTENT environment, which is why we mandate that osdep.h be included first in all qemu .c files. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature