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

["Andreas Färber" <afaerber@suse.de>]

Am 03.06.2012 14:25, schrieb Paolo Bonzini:
> 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?

As before, I dislike the use of the filename "Makefile" for files that
are not self-contained. If make is called from that deep directory, it
leads to undefined results. Either we must make sure through some clever
ifeq'ery and a local "all" target that such an attempt fails, or better
use a filename that is recognized by editors as Makefile syntax but not
used by make without explicit -f, e.g., foo.mak.

Note that I have been working on moving some more files from
Makefile.target to Makefile.objs for compilation into libhw{32,64}. I'll
defer that if people agree this is the way to restructure.

Anthony had been talking about restructuring hw/ into a more Linux-like
directory structure. Any update on that, Anthony?

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg