From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4CBz-0006GE-6Z for qemu-devel@nongnu.org; Sun, 04 Mar 2012 09:13:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S4CBw-0006QA-Vs for qemu-devel@nongnu.org; Sun, 04 Mar 2012 09:13:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49847) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S4CBw-0006Q5-MK for qemu-devel@nongnu.org; Sun, 04 Mar 2012 09:13:40 -0500 Date: Sun, 4 Mar 2012 16:13:47 +0200 From: "Michael S. Tsirkin" Message-ID: <20120304141346.GB12776@redhat.com> References: <20120304091007.GA2252@redhat.com> <20120304133122.GD12047@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH] make: remove generated objects from target dirs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, Anthony Liguori On Sun, Mar 04, 2012 at 01:44:26PM +0000, Peter Maydell wrote: > On 4 March 2012 13:31, Michael S. Tsirkin wrote: > > On Sun, Mar 04, 2012 at 01:25:59PM +0000, Peter Maydell wrote: > >> In general we don't have workarounds for "something > >> moved directory and this broke builds not from clean" > > > > Why don't we? It's cheaper than always doing > > make clean after pull. > > That's an argument for a general solution to the problem, > not a one-off bandaid fix for the bit that happened to > bite you. What I did is generic: I remove all generated headers. If you see more problems, let me know. > >> (source file moved from hw/ to . being one that's bitten > >> me before), > > > > Why would that bite anyone? AFAIK files under source control > > are handled fine. It's the generated ones that are > > a problem. > > I forget the exact failure mode but I think the problem > is that the old arm-softmmu/foo.d file is still lying > around and claims that foo.o depends on the no-longer-present > hw/foo.c. (If we didn't squash the directory structure, so > that it was arm-softmmu/hw/foo.d and arm-softmmu/hw/foo.o, > this problem wouldn't happen.) > > -- PMM Aha. A stale .d file, I see. Note that it's siginificantly different from my problem. I would think if .c is newer than .o we should just ignore .d, alternatively make the dependencies in .d somehow weaker than the implicit dependencies so they don't fail the build. I'll see whether I can come up with a solution. -- MST