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

[Daniel P. Berrangé <berrange@xxxxxxxxxx>]

On Tue, Mar 20, 2018 at 02:12:24PM +0200, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 09:44:06AM +0000, Daniel P. Berrangé wrote:
> > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > > Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> > > > 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.
> > > 
> > > If you change that, we can have issue when a system include has the same
> > > name as our local include. With "<FILE>", system header are taken first.
> > 
> > > > 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.
> > > 
> > > Not exactly, there is the notion of "system header" too.
> > > 
> > > https://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html
> > > 
> > > #include <file>
> > > This variant is used for system header files. It searches for a file
> > > named file in a standard list of system directories. You can prepend
> > > directories to this list with the -I option (see Invocation).
> > > 
> > > #include "file"
> > > This variant is used for header files of your own program. It searches
> > > for a file named file first in the directory containing the current
> > > file, then in the quote directories and then the same directories used
> > > for <file>. You can prepend directories to the list of quote directories
> > > with the -iquote option.
> > > 
> > > > 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.
> > > 
> > > I agree there is a problem with stale files. But linux, for instance,
> > > asks for a "make mrproper" to avoid this.
> > 
> > We can follow what autoconf does, and add a check to configure to see if
> > there are generated files left in the source dir, when configuring with
> > builddir != srcdir, and exit with error, telling user to clean their
> > src dir first.
> > 
> > > > 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.
> > > > 
> > > > Signed-off-by: Michael S. Tsirkin <mst@xxxxxxxxxx>
> > > 
> > > I think your idea conflicts with what Markus has started to do:
> > 
> > Yes, I don't think we should revert what Markus started.   Both ways of
> > referencing QEMU headers have downsides, but I think "..." has fewer
> > downsides that "<....">.
> 
> Could you please explain what the advantage of "" is?
> It seems to be gone since we moved headers away from
> source.

We moved *some* headers into the include/ directory tree.

I still count 650+ headers which are alongside the .c files.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel