From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:48092) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1GMI-0003mT-0k for qemu-devel@nongnu.org; Tue, 05 Mar 2019 15:08:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h1GMF-0003wy-1o for qemu-devel@nongnu.org; Tue, 05 Mar 2019 15:08:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41718) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h1GMD-0003vK-R0 for qemu-devel@nongnu.org; Tue, 05 Mar 2019 15:08:10 -0500 References: <1551723614-1823-1-git-send-email-pbonzini@redhat.com> <150efd5f-dea0-93bd-c74c-6d012f4ab7d1@redhat.com> From: Eric Blake Message-ID: Date: Tue, 5 Mar 2019 14:08:05 -0600 MIME-Version: 1.0 In-Reply-To: <150efd5f-dea0-93bd-c74c-6d012f4ab7d1@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 00/54] Kconfig conversion, excluding ARM and MIPS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth , Peter Maydell , Paolo Bonzini Cc: Yang Zhong , QEMU Developers On 3/5/19 1:45 PM, Thomas Huth wrote: >> If there are special instructions for what to do with >> build trees over the transition to kconfig, the pullreq >> cover letter would be a good place to mention them :-) > > I think you've got to do a "make distclean" inbetween... that's the old > problem when a default-configs/*.mak file gets added or erased - we do > not properly re-generate the dependencies in that case. As in this? upgrade path: build old commit make distclean git pull/branch/... build new commit downgrade path (when bisecting, backporting, ...) build new commit make distclean git branch/reset/... build old commit We obviously can't fix old commits to recognize when we are downgrading from a new commit, but is there anything we can do when upgrading to a newer commit to more gracefully inform the user if they forgot a 'make distclean' (or even better, to not make a 'make distclean' on upgrade mandatory)? In particular, once this patch series lands, developers doing a blind 'git pull' will end up in the situation: build old commit git pull build new commit # oops but may not realize that they first have to reset back to the old commit prior to 'make distclean' to guarantee that it will work. Unless I'm mistaken and 'make distclean' on an incremental build will work in spite of the missing dependencies on *.mak files even when you forgot to clean before upgrading. 'make distclean' is a heavy hammer, is there anything smaller in scope that will fix the problem without nuking everything, such as a strategic touch or rm of one particular file? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org