From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47530) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbJTH-0002Bu-QX for qemu-devel@nongnu.org; Sun, 03 Jun 2012 18:40:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SbJTF-00072l-TJ for qemu-devel@nongnu.org; Sun, 03 Jun 2012 18:40:27 -0400 Received: from cantor2.suse.de ([195.135.220.15]:35302 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SbJTF-00072A-JY for qemu-devel@nongnu.org; Sun, 03 Jun 2012 18:40:25 -0400 Message-ID: <4FCBE7D1.80907@suse.de> Date: Mon, 04 Jun 2012 00:40:17 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1338726358-30681-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1338726358-30681-1-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 00/24] per-directory Makefile snippets, limit vpath abuse List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Anthony Liguori Cc: qemu-devel@nongnu.org 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/. >=20 > 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 hos= t > 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). >=20 > Two nice side effects are: >=20 > - 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). >=20 > - 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. >=20 > - there is a lot less Makefile programming (conditionals, addprefix, > etc.), replaced by only 20 lines in rules.mak and 1 in Makefile.objs. >=20 > The series is entirely bisectable, and mostly consists of boring patche= s. > If the concept is accepted, I would like to get it in as soon as possib= le. > I have a few other cleanups on top (I stopped once I undid the diffstat > of this series :)), but they can be covered later. >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg