Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

[Nathanael Nerode]

>> To me there are legitimate reasons why a developer would want
>> "make ; ^c ; make" to work.
>
>I agree.
>
>> If by "key files" you mean "the target of the rule" I _think_ we're 
>ok.
>
>I'm thinking that some rules might alter non-target files (like
>config.cache for configure), which might cause problems.

If you didn't interrupt a subconfigure pass, you should be fine.
If you did, you should delete the appropriate config.cache, the 
appropriate Makefile, and anything else generated or modified by that 
'configure', and then you should be fine.  At least that's my belief.

--Nathanael

Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

[Andrew Cagney]

>>> To me there are legitimate reasons why a developer would want
>>> "make ; ^c ; make" to work.
> 
>>
>>I agree.
>>
> 
>>> If by "key files" you mean "the target of the rule" I _think_ we're 
> 
>>ok.
>>
>>I'm thinking that some rules might alter non-target files (like
>>config.cache for configure), which might cause problems.
> 
> 
> If you didn't interrupt a subconfigure pass, you should be fine.
> If you did, you should delete the appropriate config.cache, the 
> appropriate Makefile, and anything else generated or modified by that 
> 'configure', and then you should be fine.  At least that's my belief.

Right, however, there lies the problem.

In the past, with separate configure / build phases, this was easy - 
cntrl-c the configure and blow away the directory tree.  Now, with the 
configure phases intermingled with the build phases, doing this has 
become that much harder.

All that is hopefully needed is a bit of dependency tweaking - touch 
something after the configure phase completes and depend on that.

Andrew

Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

[Geoff Keating]

Andrew Cagney <ac131313@redhat.com> writes:

> In the past, with separate configure / build phases, this was easy -
> cntrl-c the configure and blow away the directory tree.  Now, with the
> configure phases intermingled with the build phases, doing this has
> become that much harder.
> 
> All that is hopefully needed is a bit of dependency tweaking - touch
> something after the configure phase completes and depend on that.

Ideally, if one wanted to build GDB and not GCC (for instance), it
would be as easy as saying 'make all-gdb'.  Since the Makefile now
runs configure, the GCC configury shouldn't be run.

I do think that 'make ; ^c ; make' should work.  The ^c might be
something like 'disk full' or 'oops, foo/configure fails with exit 1'
or 'oops, cc1 has the wrong permissions'.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

[Alexandre Oliva]

On Jan  2, 2003, Geoff Keating <geoffk@geoffk.org> wrote:

> I do think that 'make ; ^c ; make' should work.

It mostly works.  I think the only failure scenario right now is when
running sub-configures of sub-packages fails.  There's really no way
to help this except by adding code supporting running of
sub-sub-configures in their parent Makefiles.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

[DJ Delorie]

> To me there are legitimate reasons why a developer would want
> "make ; ^c ; make" to work.

I agree.

> If by "key files" you mean "the target of the rule" I _think_ we're ok.

I'm thinking that some rules might alter non-target files (like
config.cache for configure), which might cause problems.

Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

[Doug Evans]

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.

Re: ^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

[DJ Delorie]

> 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.

^c now disallowed? (was Re: "cd dir && $(MAKE)", not "cd dir; $(MAKE)")

[Doug Evans]

Browsing the gdb archives I came across this.

Nathanael Nerode writes:
 > But interrupting 'make' in the middle can give 
 > all manner of screwy results now; don't rely on it.

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)" ?


(*1): Which is effectively the same as saying rm -rf *
(assuming objdir != srcdir of course) is required if
you ^c and want the next `make' to work (assuming you don't want to
go to the trouble of figuring out what state the tree is in that will
screw up a subsequent make).  Ugh.