[Top][All Lists]

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

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

From: Andreas Färber
Subject: Re: [Qemu-devel] [PATCH 00/24] per-directory Makefile snippets, limit vpath abuse
Date: Mon, 04 Jun 2012 00:40:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0

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?


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

reply via email to

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