[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-s390x] [Qemu-devel] [PATCH] qemu: include generated files with

From: Stefan Weil
Subject: Re: [qemu-s390x] [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""
Date: Tue, 20 Mar 2018 17:33:42 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

Am 20.03.2018 um 02:54 schrieb Michael S. Tsirkin:
> 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.

Hello Michael,

the compiler (or to be more precise the preprocessor) works as you
describe it, so technically all include files which are only found by
searching the include paths would be found faster with <> than with "":
the unsuccessful search relative to the source file directory would be
omitted. Practically this will not save much build time because of
caching effects. So the suggested change is not required to get faster
build speed.

Using <> for system include files and "" for local include files is a
convention, and as far as I know most projects adhere to that
convention. So does QEMU currently. Such conventions are not only
important for humans, but also for tools. There are more tools than the
C preprocessor which handle <> and "" differently. For example the GNU
compiler uses -MD or -MMD to automatically generate dependency rules for
make. While -MD generates dependencies to all include files, -MMD does
so only for user include files, but not for system include files. "user"
and "system" means the different forms how include statements are
written. QEMU still seems to use -MMD:

rules.mak:QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(@D)/$(*F).d

Other tools like static code analysers could restrict their warning and
error messages to user include files and ignore problems in system
include files.

Very large projects often split in sub projects, maybe one of them
describing the API. Then that API headers are similar to system headers
and can be included using <>, although they still belong to the same
larger project. Do we have a stable QEMU API described in a (small)
number of include files which typically do not change? If yes, then
those include files could be included using <> because we don't need
them in dependency lists or in static code analysis reports.

For all other QEMU include files, I'd stick to using "".


reply via email to

[Prev in Thread] Current Thread [Next in Thread]