From patchwork Fri May 25 14:30:45 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Matz X-Patchwork-Id: 161375 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 980EDB6F86 for ; Sat, 26 May 2012 00:31:11 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1338561071; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Date: From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=4KmHPqFlGLQqha4RneqS uNmT+f0=; b=uV6iNMqa2285IRB/qodJxVxOlHvSxWoDTbk9unhiCFqJXyqEZ5QI nuDcpqHXvWDIX5I3D3cfa3aqf/mAanSgVrpwaqlZ8Mw6AriIVaX9XBVr9BLFT87j yRA02qf/j3GKwETBNdU1+glm5wPQSczXZ8H+ETqvqWVPPPwfnHRljOw= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=ot51XO6cfrFkZDMbUJwnzPwkYpj13Wc6ByWR0Cbhl31J2W5rRd+2hqZ+U2PL61 ZySEzZSLgbYKy7h3xy9ppzJNxMIzYSF2oZlPzXXta26ryjaM044/bgLQxVcPzqJM 3wiS6eplFuLhQVdMiKVmywO6tNlatG9EPutvBeHr1ejDs=; Received: (qmail 29993 invoked by alias); 25 May 2012 14:31:07 -0000 Received: (qmail 29983 invoked by uid 22791); 25 May 2012 14:31:06 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 May 2012 14:30:47 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 76F6B9604E; Fri, 25 May 2012 16:30:46 +0200 (CEST) Date: Fri, 25 May 2012 16:30:45 +0200 (CEST) From: Michael Matz To: Paolo Bonzini , Rainer Orth Cc: gcc-patches@gcc.gnu.org Subject: unwind.h installation causes rebuilds Message-ID: MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi, I've noticed that libitm is always rebuild with a non-bootstrap tree even with merely a sequence of two makes. The reason turns out to be that installation of unwind.h from libgcc, which is always done with a simple make: # make # make -d ... dest=../.././gcc/include/tmp$$-unwind.h; \ cp unwind.h $dest; \ chmod a+r $dest; \ sh ../../../gcc/libgcc/../move-if-change $dest ../.././gcc/include/unwind.h (this is still fine, because it uses move-if-change) ... make install-leaf DESTDIR=../.././gcc \ slibdir= libsubdir= MULTIOSDIR=. ... /bin/sh ../../../gcc/libgcc/../mkinstalldirs ../.././gcc/include /usr/bin/install -c -m 644 unwind.h ../.././gcc/include This one updates the mtime of gcc/include/unwind.h, and is the problematic one, ultimately resulting in: Prerequisite `/matz/gcc/svn/real-trunk/dev/gcc/include/unwind.h' is newer than target `aatree.lo'. And all of libitm (our only c++ library) is rebuilt as all objects therein have a dependency on unwind.h. There are multiple variants to fix: a) use install -p (or -C) generally for all INSTALLs in all makefiles b) use a) for only libgcc Makefile c) don't repeatedly install the same files on a remake even though nothing was compiled newly (perhaps some stamp files could be used to make leaf-install a no-op if nothing new was built?) I've checked that hardcoding -p for INSTALL in the top-level Makefile solves this problem (see patch), but perhaps you prefer one of the others (or can think of something else entirely). Ciao, Michael. Index: configure.ac =================================================================== --- configure.ac (revision 187708) +++ configure.ac (working copy) @@ -93,8 +93,8 @@ srcpwd=`cd ${srcdir} ; ${PWDCMD-pwd}` # We pass INSTALL explicitly to sub-makes. Make sure that it is not # a relative path. -if test "$INSTALL" = "${srcdir}/install-sh -c"; then - INSTALL="${srcpwd}/install-sh -c" +if test "$INSTALL" = "${srcdir}/install-sh -c -p"; then + INSTALL="${srcpwd}/install-sh -c -p" fi # Set srcdir to "." if that's what it is. Index: config/proginstall.m4 =================================================================== --- config/proginstall.m4 (revision 187708) +++ config/proginstall.m4 (working copy) @@ -54,12 +54,12 @@ case $as_dir/ in echo one > conftest.one echo two > conftest.two mkdir conftest.dir - if "$as_dir/$ac_prog$ac_exec_ext" -c conftest.one conftest.two "`pwd`/conftest.dir" && + if "$as_dir/$ac_prog$ac_exec_ext" -c -p conftest.one conftest.two "`pwd`/conftest.dir" && test -s conftest.one && test -s conftest.two && test -s conftest.dir/conftest.one && test -s conftest.dir/conftest.two then - ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c" + ac_cv_path_install="$as_dir/$ac_prog$ac_exec_ext -c -p" break 3 fi fi