Re: [Qemu-arm] [Qemu-devel] [PATCH] qemu: include generated files with <> and not ""

["Michael S. Tsirkin" <mst@redhat.com>]

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 file identified
by the specified sequence between the " delimiters. The named source file is searched
for in an implementation-defined manner. If this search is not supported, or if the search
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 original
directive.



> 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 "".
> 
> Regards
> Stefan

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
to qemu.

Exceptions are elf.h glib-compat.h and the generated trace.h.

Let's
	mv include/* include/qemu/ ?

-- 
MST