From owner-freebsd-current@FreeBSD.ORG Tue May 6 15:50:17 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 789E737B401 for ; Tue, 6 May 2003 15:50:17 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27ABA43FA3 for ; Tue, 6 May 2003 15:50:16 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id IAA20704; Wed, 7 May 2003 08:50:09 +1000 Date: Wed, 7 May 2003 08:50:08 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Lars Eggert In-Reply-To: <3EB8109D.2060307@isi.edu> Message-ID: <20030507083913.Y18014@gamplex.bde.org> References: <3EB8109D.2060307@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: hardcoded -C argument to ${INSTALL} X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2003 22:50:17 -0000 On Tue, 6 May 2003, Lars Eggert wrote: > I'm putting a script together that will remove stale pieces after an > installworld, and my find+mtime approach chokes, because some uses of > ${INSTALL} in the Makefiles hardcode the -C argument, which will cause > file modification times to not be updated if the files are identical. > > For example: > include/Makefile > share/mk/bsd.incs.mk > sys/boot/efi/loader/Makefile > sys/boot/alpha/common/Makefile.common > ... > > I'm no guru on the buildworld process, so I'm wondering whether this is > by design, or an oversight? Can the -C be removed without ill effects? -C is important for includes because it prevents most executables (including freshly built ones) becoming out of date every time you install includes. -C is used for very important executables like ld-elf.so.1 for its side effect of giving an atomic-as-possible install. Atomic-as-possible installs should be the default, and install(1) has made some progress towards this, but it is not there yet -- by default, it still begins with unlinking the target. Bruce