Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben: > 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
You're right that there is a conflict, even though only in one direction: "trace.h" is unambiguously the local trace.h in our source tree, but <trace.h> refers to the same local header rather than the system header as you would expect. An easy way to resolve this conflict would be using -iquote rather than -I for directories in the source tree, so that <trace.h> unambiguously refers to the system header and "trace.h" unambiguously refers to the QEMU header. > 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. > > 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. > > This (untested) patch is just to start the discussion and does not > change all of the codebase. If there's agreement, this will be > run on all code to converting code to this scheme. Renaming files is always painful. If that's the fix, the cure might be worse than the disease. As far as I know, the conflict is only theoretical, so in that case I'd say: If it ain't broke, don't fix it. Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel