[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [Qemu-devel] [PATCH] qemu: include generated files with
Michael S. Tsirkin
Re: [qemu-s390x] [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""
Tue, 20 Mar 2018 19:10:42 +0200
On Tue, Mar 20, 2018 at 05:33:42PM +0100, Stefan Weil wrote:
> 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
To my knowledge, and according to my limited testing,
system headers in this context means
the default ones not supplied with -I.
If I had to guess, that is the definition most other tools
are likely to use.
> Other tools like static code analysers could restrict their warning and
> error messages to user include files and ignore problems in system
> include files.
Could you give some exacmples of tools like that?
IMHO they would not work correctly if they did not treat
include directives the way compiler does.
C standard is pretty explicit that the only difference
is extra directories searched:
A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source
by the specified sequence between the " delimiters. The named source file is
for in an implementation-defined manner. If this search is not supported, or if
fails, the directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including > characters, if any) from the
> 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 "".
Most people know that system headers are the ones in /usr/include
The distinction that they are pulled in with include ""
is a QEMU construct.
If we want to be able to distinguish between internal and
external headers, the standard way to do it
in C is by prefixing the names with qemu/ qemu- or qemu_.
In fact we kind of already do this - if you see a name with
a slash in there you can be pretty sure it's internal
Exceptions are elf.h glib-compat.h and the generated trace.h.
mv include/* include/qemu/ ?
Re: [qemu-s390x] [PATCH] qemu: include generated files with <> and not "", Eric Blake, 2018/03/20
Re: [qemu-s390x] [Qemu-devel] [PATCH] qemu: include generated files with <> and not "", Stefan Weil, 2018/03/20
Re: [qemu-s390x] [Qemu-devel] [PATCH] qemu: include generated files with <> and not "", Daniel P . Berrangé, 2018/03/20
- Re: [qemu-s390x] [Qemu-devel] [PATCH] qemu: include generated files with <> and not "",
Michael S. Tsirkin <=