This is the mail archive of the
mailing list for the binutils project.
Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")
- From: DJ Delorie <dj at delorie dot com>
- To: dje at transmeta dot com
- Cc: neroden at twcny dot rr dot com, gdb at sources dot redhat dot com, binutils at sources dot redhat dot com
- Date: Fri, 27 Dec 2002 14:47:20 -0500
- Subject: Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")
- References: <200212271914.LAA04845@casey.transmeta.com>
> Ugh. This is an effect of the configury change that
> I hadn't anticipated. This is going to be a major pain IMHO.
> Are the powers that be really ok with saying "just don't do that (*1)" ?
I don't think this is really new - hitting ^C in the middle of a
configure before may have left you unreliable too, and target
configures were done during the build before.
I think a better solution to support is documenting how to do a
partial configure/build without needing the ctrl-c. So that you'd
just say "make all-this all-that" and know that it's doing the right
minimal set of rules.
I would be amenable to altering the makefiles to delete key files on
failure, to ensure they get rebuilt the next time around. But a
ctrl-c interrupt would skip that step as well, so I don't see how we
could do that reliably. The best we can do is keep the window of
misopportunity limited creating the key files only as the last step.
I.e, move in place after complete rather than redirect to the final
file. Autoconf already works mostly this way.
The only way we could claim ctrl-c was reliable was is make itself
deleted the key files if that rule is interrupted. I don't think we
can rely on that being portable, but at least we could claim that for
makes that support that, we claim that it works reliably.