Re: [Qemu-devel] [PATCH 00/24] per-directory Makefile snippets, limit vpath abuse

[Lluís Vilanova]

Paolo Bonzini writes:

> One source of complexity in the QEMU source is that we have a very
> shallow tree for a source code of over 750,000 lines of code.  In
> fact, one third of these lines alone is in one directory, hw/.

> As a prerequisite to cleaning up the structure, but as a worthwhile
> step on its own, this patchset cleans up the build system so that
> separate directories have their own Makefile snippet.  As in the Linux
> kernel build system, the overall build system is generally flat (in
> the case of QEMU, with one recursive invocation per emulation target).
> Subdirectories do not include complete Makefiles, instead they only host
> the declarations for a few variables (common-obj-y, universal-obj-y,
> obj-y, etc.).  Definitions for all the directories are merged with a
> little GNU Make magic (not much, only 20 lines).

> Two nice side effects are:

> - we can match the source tree and the object tree (for example the
>   per-target device models will be in XYZ-softmmu/hw, not in
>   XYZ-softmmu; those that are compiled once will be in hw/ rather
>   than in the root).

> - because the resolution of nested makefiles tracks the nested
>   directory, there is no need to use VPATH to find sources in
>   the hw/ and target-*/ directory.

> - there is a lot less Makefile programming (conditionals, addprefix,
>   etc.), replaced by only 20 lines in rules.mak and 1 in Makefile.objs.

> The series is entirely bisectable, and mostly consists of boring patches.
> If the concept is accepted, I would like to get it in as soon as possible.
> I have a few other cleanups on top (I stopped once I undid the diffstat
> of this series :)), but they can be covered later.

> Thoughts, approvals, rejections?

Excellent!

I've wanted for long to have a few "generic" config variables defining what to
compile:

- CONFIG_TARGET (e.g., x86, arm, etc.)
- CONFIG_MODE (softmmu, user)
- CONFIG_? (tcg, kvm, xen)
- CONFIG_USER_OS (linux, bsd)

With this, it should be much more easy to lay the files out in a deeper and much
more "square-headed" hierarchy like
"<sybsystem>/<mode>/<user-os>/<?>/<target>" (where any of them is optional),
in the hopes to make it easier to split and locate code that depends on the
configuration.

With this, code can be separated into subsystems along time, so that you could
end up with "exec/tcg", "exec/kvm", "exec/user/linux/tcg/i386", "trace/softmmu",
etc.

This should also make it simpler to use soft-links and/or include paths to refer
to configuration-specific contents with a "generic" path (similar to what linux
does with "include/asm -> arch/x86/include/asm").



Lluis

-- 
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth