Re: [Qemu-devel] [PATCH 00/67] include path cleanup

[Paolo Bonzini]

On 03/05/2018 21:50, Michael S. Tsirkin wrote:
> At the moment during build we have multiple subdirectories of the source
> tree on the search path for include files.  This includes source
> directory itself, tcg and accel/tcg subdirectories, target-specific
> source subdirectory and the include subdirectory.
> 
> The result is that there are many ways to include each
> specific file, e.g. for a file in the include directory:
> 
> #include "dir/foo.h"
> #include "include/dir/foo.h"
> 
> (We actually do both).
> 
> OTOH local headers can be included with
> #include "foo.h"
> #include "dir/foo.h"
> 
> There are also target-specific headers and they are even
> trickier - e.g. try to guess which file does
> #include "cpu.h"
> pull in?  The answer actually depends on which target is built.
> 
> It is also quite easy to place an external header outside of
> include/ as nothing will catch this misuse.
> 
> In an attempt to simplify this situation, this changes the build to look
> for headers in a single directory under the source tree: include/
> (generated files are still spread around a bit, this is left for another
> patchset - and RFC of that I posted earlier).
> 
> This way, one can always find any header under include/
> (and sometimes follow from there to another directory).
> 
> A nice side effect of this refactoring is that it makes it easy to
> identify external headers which are not under include/.

Yes, this was always the intended usage.

> I decided not to actually move any headers around -
> instead I created small stub files using include_next
> which pull in the original files.

For the RFC is okay, but I think we should at least see which headers
can just get a home in include/ before applying the series.  Perhaps we
can add an include-from-topsrcdir/ directory with the #include_next
directives so that the todo list is clear.

> This way we can move the headers gradually - in particular it is often
> benefitial to split a header up with external parts under include and
> internal ones with the source.

I agree.

> Note that it's already benefitial even in this form, since
> - it's now easy to see there is an external header outside include
>   that requires work
> - reader can simply look at the header and immediately know
>   where to look for it
> 
> Target specific files are pulled in using preprocessor which is still
> tricky but arguably easier to understand than makefile tricks.

Another possibility is to directories like include/target/<XXX>, or
target/<XXX>/include/.

Paolo