Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@transmeta.com>
To: DJ Delorie <dj@delorie.com>
Cc: neroden@twcny.rr.com, gdb@sources.redhat.com,
	binutils@sources.redhat.com
Subject: Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")
Date: Fri, 27 Dec 2002 12:42:00 -0000	[thread overview]
Message-ID: <15884.47902.892560.313412@casey.transmeta.com> (raw)
In-Reply-To: <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.


  reply	other threads:[~2002-12-27 20:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-27 11:16 Doug Evans
2002-12-27 11:47 ` DJ Delorie
2002-12-27 12:42   ` Doug Evans [this message]
2002-12-27 12:46     ` DJ Delorie
2002-12-27 20:16 Nathanael Nerode
2003-01-02 14:56 ` Andrew Cagney
2003-01-02 17:28   ` Geoff Keating
2003-01-02 20:10     ` Alexandre Oliva

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=15884.47902.892560.313412@casey.transmeta.com \
    --to=dje@transmeta.com \
    --cc=binutils@sources.redhat.com \
    --cc=dj@delorie.com \
    --cc=gdb@sources.redhat.com \
    --cc=neroden@twcny.rr.com \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox