From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org (Zsh hackers list)
Subject: Re: make oddity
Date: Mon, 20 Dec 2010 18:46:19 -0800 [thread overview]
Message-ID: <101220184619.ZM26905@torch.brasslantern.com> (raw)
In-Reply-To: <22105.1292865347@csr.com>
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.
prev parent reply other threads:[~2010-12-21 2:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-20 17:15 Peter Stephenson
2010-12-20 21:01 ` Peter Stephenson
2011-01-09 17:00 ` Peter Stephenson
2010-12-21 2:46 ` Bart Schaefer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=101220184619.ZM26905@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).