From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwgYQ-0007pB-K9 for qemu-devel@nongnu.org; Sat, 19 Jan 2013 17:06:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TwgYP-0002Df-IF for qemu-devel@nongnu.org; Sat, 19 Jan 2013 17:06:22 -0500 Received: from mail-ee0-f48.google.com ([74.125.83.48]:55788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TwgYP-0002DL-Bc for qemu-devel@nongnu.org; Sat, 19 Jan 2013 17:06:21 -0500 Received: by mail-ee0-f48.google.com with SMTP id t10so2351314eei.21 for ; Sat, 19 Jan 2013 14:06:20 -0800 (PST) Sender: Paolo Bonzini Message-ID: <50FB18D8.7010805@redhat.com> Date: Sat, 19 Jan 2013 23:06:16 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1358590008-1681-1-git-send-email-pbonzini@redhat.com> <50FAE1E3.6010309@suse.de> In-Reply-To: <50FAE1E3.6010309@suse.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH for 1.4 0/4] Simplify Makefile.objs some more List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org Il 19/01/2013 19:11, Andreas Färber ha scritto: >> > The patches are mostly mechanical substitutions, and there is no >> > user-visible change---neither in total build time, nor in the files that >> > are linked into the executables. > Without having tested this yet I want to remind that it is necessary for > qom/cpu.c to be built twice Hmm, it's not anymore actually (since libuser was removed). It hasn't been built twice for a month and apparently nothing broke. > , to not run into similar issues like > util/oslib-posix.c. The only dependency is #if !defined(CONFIG_USER_ONLY) int kvm_fd; bool kvm_vcpu_dirty; #endif struct KVMState *kvm_state; struct kvm_run *kvm_run; Plenty of other fields are meaningless for !CONFIG_USER_ONLY but are unconditionally present in struct CPUState. Given this inconsistency, why is it still useful to build it twice? Paolo