From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6790 invoked by alias); 21 Dec 2010 02:46:30 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28545 Received: (qmail 19643 invoked from network); 21 Dec 2010 02:46:27 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <101220184619.ZM26905@torch.brasslantern.com> Date: Mon, 20 Dec 2010 18:46:19 -0800 In-reply-to: <22105.1292865347@csr.com> Comments: In reply to Peter Stephenson "make oddity" (Dec 20, 5:15pm) References: <22105.1292865347@csr.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org (Zsh hackers list) Subject: Re: make oddity MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Dec 20, 5:15pm, Peter Stephenson wrote: } } I had to work around a problem with make in releasing 4.3.11: in } previous releases 'make' from a clean directory performed the equivalent } of 'make prep' in the Src directory, this time it didn't. Oops. This must in some way be my fault. On Saturday last I committed this change: Index: Src/Makefile.in @@ -109,7 +109,7 @@ @CONFIG_MK@ -Makemod prep: $(CONFIG_INCS) $(dir_top)/config.modules +Makemod: $(CONFIG_INCS) $(dir_top)/config.modules @case $(sdir_top) in \ /*) top_srcdir=$(sdir_top) ;; \ *) top_srcdir=$(subdir)/$(sdir_top) ;; \ @@ -119,6 +119,7 @@ '$$top_srcdir/$(subdir)/mkmakemod.sh $(subdir) Makemod'; \ cd $(dir_top) && \ $(SHELL) $$top_srcdir/$(subdir)/mkmakemod.sh $(subdir) Makemod +prep: Makemod @$(MAKE) -f Makemod $(MAKEDEFS) prep || rm -f Makemod .PHONY: prep This has been working fine for me here for literally years, so I didn't expect it to cause any disruption. The reason for the change is so that "make prep" doesn't needlessly re-run mkmakemod.sh, which I found to be stepping on something or other (I forget now what, it's been a very long time ago). However, apparently in some circumstances that I simply must never have tested, Makemod is implicitly rebuilt and that fails to implicitly rebuild "prep". PWS's change in 28544 re-introduces that explicit "make prep" at another place in the build, but without the explicit removal of Makemod if the action fails. Seen from this perspective I realize the change I made to Makefile.in missed an important point, which is that Makemod can't be considered successfully built unless "make prep" succeeds ... my change has inadvertently removed that condition. I'm not certain of the best way to resolve all the issues. It would seem that Makemod and prep, taken as targets, have a strange partial dependency on one another: prep can't be run withoug Makemod, and Makemod is built by mkmakemod.sh, but Makemod isn't done unless prep has been successful; conversely, if nothing else has changed and prep succeeded before, then mkmakemod.sh isn't needed for prep.