[Top][All Lists]

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

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

From: Eric Blake
Subject: Re: [Qemu-ppc] [PATCH] qemu: include generated files with <> and not ""
Date: Tue, 20 Mar 2018 11:12:00 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/19/2018 08:54 PM, Michael S. Tsirkin wrote:
QEMU coding style at the moment asks for all non-system
include files to be used with #include "foo.h".

[I'm replying without having read the rest of the thread, so bear with me if I repeat some of the other comments that have already been made]

And Markus even just did a cleanup along those lines.

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.

It's also nice when "file" means file belonging to our project, and <file> means 3rd-party file. So we have to choose which semantics are easier; perhaps better Makefile rules that prevent us from seeing stale files is a better solution than figuring out which files are generated.

As generated files are not in the search directory (unless the build
directory happens to match the source directory),

Why can't we fix Makefile to include BOTH the build and the source directories (to pick up generated files first, and then version-controlled files), and possibly include logic to simplify to a single -I instead of two when doing in-tree builds?

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

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.

I'm not sure I'm a fan of this patch yet, if there may be other alternatives that solve the real issue of stale generated files breaking incremental builds.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

reply via email to

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