On Tue, Mar 20, 2018 at 01:10:41PM +0000, Stefan Hajnoczi wrote: > On Tue, Mar 20, 2018 at 03:54:36AM +0200, Michael S. Tsirkin wrote: > > 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. > > > > 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. > > > > 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. > > > > 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. > > Stale header files are a pain. I often do make distclean before > checking out a radically different QEMU version to avoid the problem. > > This patch trades off the stale header file issue for a new approach to > using <> vs "", which will be hard to use consistently
The proposed rule is to use <> everywhere except if the file is in the source directory. It will be very easy to use consistently for the simple reason that compiler will enforce it. If you use <> for a header in the current directory build fails. So you are forced to use "". > in the future > since it is unconventional. All compilers I know without exception implement include <> meaning look in -I search path, and include "" meaning look in current directory then in -I search path. Looks conventional to me. > Is the build time improvement worth it (please post numbers)? > > Stefan Haven't tested it frankly. Will it convince anyone if it's marginally faster? -- MST