On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote: > Our current scheme is to use > #include "" > for internal headers, and > #include <> > for external ones. > > Unfortunately this is not based on compiler support: from C point of > view, the "" form merely looks up headers in the current directory > and then falls back on <> directories. > > Thus, for example, a system header trace.h - should it be present - will > conflict with our local trace.h
If our local "trace.h" is in the current directory, then using "" is right and you can still use <trace.h> to get the system version. If our local trace.h is in include/ top level, then it is going to block use of the system trace.h regardless of whether we use <> or "" Fortunately our include/ tree uses sub-dirs, so we would typically use #include "$subdir/trace.h" and #include <trace.h> would still find the system header. We just have to be careful we don't add stuff at the top level of our include/ dir with names that are liable to clash. This might suggest renaming include/elf.h to include/qemu/elf.h, or just moving elf.h to the qemu/ subdirectory. Likewise include/glib-compat.h might be better moved to qemu/ subdirectory. > As another example of problems, a header by the same name in the source > directory will always be picked up first - before any headers in > the include directory. There's only a couple of headers in the top level of our include/ directory - everything else is pulled in with a named path eg #include "block/block_int.h", so that would not conflict with reference to a bare #include "block_int.h" from the current directory. > Let's change the scheme: make sure all headers that are not > in the source directory are included through a path > starting with qemu/ , thus: > > #include <> > > headers in the same directory as source are included with > > #include "" > > as per standard. As stated before, I consider this a step backwards - it is a good clear standard to use "" for project local includes and <> for 3rd party / system includes IMHO. The change doesn't do anything beneficial for the two scenarios described above AFAICT. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
