From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtfuQ-000462-8C for qemu-devel@nongnu.org; Mon, 01 Jul 2013 11:20:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UtfuL-0003VQ-DM for qemu-devel@nongnu.org; Mon, 01 Jul 2013 11:20:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtfuK-0003V4-Br for qemu-devel@nongnu.org; Mon, 01 Jul 2013 11:20:48 -0400 Message-ID: <51D19E4A.4050706@redhat.com> Date: Mon, 01 Jul 2013 17:20:42 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1371576844-28743-1-git-send-email-mjt@msgid.tls.msk.ru> <51D04EA6.6020806@suse.de> <51D05090.40304@msgid.tls.msk.ru> <51D18681.6050805@redhat.com> <51D1959B.50803@msgid.tls.msk.ru> <51D1964F.6040904@suse.de> <51D197D7.6070102@redhat.com> <51D19AFA.2090707@msgid.tls.msk.ru> In-Reply-To: <51D19AFA.2090707@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: =?ISO-8859-15?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org Il 01/07/2013 17:06, Michael Tokarev ha scritto: > So instead of this, we may have in the top-level Makefile: > > obj-i386-y += hw/i386/msi.o hw/i386/irq.o hw/i386/kvm.o > > Or, if you prefer programmatic expansion, > > list-i386-y += msi.o irq.o kvm.o > obj-i386-y += $(addprefix hw/i386/, $(list-i386-y)) If I have to choose my poison, I prefer the directory multiple times. But both seem worse than what we have now? > So the difference is just the addition of the pathnames, > not the logic or ifdeffery. Even after you factor in user-level vs. softmmu, tools, KVM vs. Xen vs. TCG, and all that? >> Conflicts in a small file are also way easier to solve, even if there >> are more conflicting files. > > Conflicts? Which conflicts? You mean merge conflicts? > If yes, it does not really matter be it small file or large > file. When diff3 goes haywire because you're merging features back to a 4-year-old version, it matters a lot. > (Again, the "half" here refers to the fact that some variables > gets prefixed by the subdir automatically while some doesn't). Which *-obj-y variables do not get prefixed? > So before sending patches, can we at least agree (or not) that > specifying paths explicitly (either using dir/obj.o or by calling > addprefix) is not THAT bad or it should be avoided entirely? addprefix is bad. Specifying paths explicitly is not bad _per se_, but if a directory is used to group related code, I think the Makefile should also be separated. For example in the future we may have Kconfig files in hw/*, and of these three possibilities, (1) and (2) would be worse than (3): 1) use a single huge Kconfig file for all devices, use a single Makefile.objs; 2) split Kconfig, keep a single Makefile.objs file; 3) split both the Kconfig and the Makefile.objs files. > (I dislike the recursive sub-make approach because when you have > everything in one make it is much easier to see all dependencies > and plan the work, instead of running a ton of submakes first, > each checking if its own subdir is up to date). I agree. And again QEMU is doing half-this half-that, but I don't see any alternative. Paolo