[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] qemu: include generated files with <> and not ""
Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit : > QEMU coding style at the moment asks for all non-system > include files to be used with #include "foo.h". > However this rule actually does not make sense and > creates issues for when the included file is generated. If you change that, we can have issue when a system include has the same name as our local include. With "<FILE>", system header are taken first. > In C, include "file" means look in current directory, > then on include search path. Current directory here > means the source file directory. > By comparison include <file> means look on include search path. Not exactly, there is the notion of "system header" too. https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html #include <file> This variant is used for system header files. It searches for a file named file in a standard list of system directories. You can prepend directories to this list with the -I option (see Invocation). #include "file" This variant is used for header files of your own program. It searches for a file named file first in the directory containing the current file, then in the quote directories and then the same directories used for <file>. You can prepend directories to the list of quote directories with the -iquote option. > As generated files are not in the search directory (unless the build > directory happens to match the source directory), it does not make sense > to include them with "" - doing so is merely more work for preprocessor > and a source or errors if a stale file happens to exist in the source > directory. I agree there is a problem with stale files. But linux, for instance, asks for a "make mrproper" to avoid this. > This changes include directives for all generated files, across the > tree. The idea is to avoid sending a huge amount of email. But when > merging, the changes will be split with one commit per file, e.g. for > ease of bisect in case of build failures, and to ease merging. > > Note that should some generated files be missed by this tree-wide > refactoring, it isn't a big deal - this merely maintains the status quo, > and this can be addressed by a separate patch on top. > > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx> I think your idea conflicts with what Markus has started to do: commit d8e39b70625d4ba1e998439d1a077b4b978930e7 Author: Markus Armbruster <armbru@xxxxxxxxxx> Date: Thu Feb 1 12:18:28 2018 +0100 Use #include "..." for our own headers, <...> for others System headers should be included with <...>, our own headers with "...". Offenders tracked down with an ugly, brittle and probably buggy Perl script. Previous iteration was commit a9c94277f0. Delete inclusions of "string.h" and "strings.h" instead of fixing them to <string.h> and <strings.h>, because we always include these via osdep.h. Put the cleaned up system header includes first. While there, separate #include from file comment with exactly one blank line. commit a9c94277f07d19d3eb14f199c3e93491aa3eae0e Author: Markus Armbruster <armbru@xxxxxxxxxx> Date: Wed Jun 22 19:11:19 2016 +0200 Use #include "..." for our own headers, <...> for others Tracked down with an ugly, brittle and probably buggy Perl script. Also move includes converted to <...> up so they get included before ours where that's obviously okay. Thanks, Laurent _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |