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: Doug Evans <dje at transmeta dot com>
- To: DJ Delorie <dj at delorie 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 12:42:06 -0800 (PST)
- Subject: Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")
- References: <200212271914.LAA04845@casey.transmeta.com><200212271947.gBRJlK125992@envy.delorie.com>
DJ Delorie writes:
> > 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.
PLEASE don't confuse my questioning of ^c wth my playing
around with trying to get something working (*1) (instead of doing
make all-foo install-foo).
To me there are legitimate reasons why a developer would want
"make ; ^c ; make" to work. S/he may have edited a file,
typed make, and then said "Oh shit, I forgot something."
Waiting for gdb to have to link (to pick something arbitrary that
takes awhile to finish) before being able to go back and fix the problem
is unacceptable (IMO of course).
The existing target-configure case is a good argument.
However, it is localized and recognizable. I can (or at least could)
easily know when my ^c was going to screw something.
The window appears to be MUCH bigger now.
> 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.
Note that I'm not asking for 100% reliability.
Rather, my impression is that reliability has gone from 90-ish%
to 30-ish%. Blech.
If by "key files" you mean "the target of the rule" I _think_ we're ok.
Doesn't every make (that we care about) delete the target file
if interrupted? (setting aside .PRECIOUS - heh, got to be a LOTR
pun in there somewhere :-)).
(*1): I'm sorry I mentioned it. I frequently use make all-foo.
The point was to illustrate how I ran into "cd dir ; $(MAKE)"
which is obviously a legitimate bug regardless of how it was tripped over.