Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.
@ 2009-03-02  0:10 Doug Evans
  2009-03-02  0:55 ` Tom Tromey
  0 siblings, 1 reply; 6+ messages in thread
From: Doug Evans @ 2009-03-02  0:10 UTC (permalink / raw)
  To: gdb-patches

Hi.

IWBN if "make clean" cleared out .deps/*.

Otherwise when something gets moved then dependencies still refer to
the old place and require the equivalent of a "make distclean"
to get make working again (which is a bit heavyweight).
IWBN if "make clean" was sufficient.

Ok to check in?

2009-03-01  Doug Evans  <dje@google.com>

	* Makefile.in (clean): rm -f $(DEPDIR)/*.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.1068
diff -u -p -r1.1068 Makefile.in
--- Makefile.in	17 Feb 2009 17:56:50 -0000	1.1068
+++ Makefile.in	2 Mar 2009 00:05:29 -0000
@@ -1124,6 +1124,7 @@ clean mostlyclean: $(CONFIG_CLEAN)
 	rm -f gdb[0-9]$(EXEEXT)
 	rm -f test-cp-name-parser$(EXEEXT)
 	rm -f xml-builtin.c stamp-xml
+	rm -f $(DEPDIR)/*
 
 .PHONY: clean-tui
 clean-tui:


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.
  2009-03-02  0:10 [RFA] Makefile.in (clean): rm -f $(DEPDIR)/* Doug Evans
@ 2009-03-02  0:55 ` Tom Tromey
  2009-03-02  0:58   ` Doug Evans
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Tromey @ 2009-03-02  0:55 UTC (permalink / raw)
  To: Doug Evans; +Cc: gdb-patches

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> Otherwise when something gets moved then dependencies still refer to
Doug> the old place and require the equivalent of a "make distclean"
Doug> to get make working again (which is a bit heavyweight).

Could you expand a bit on exactly what fails?  Do you see an error?  A
missed rebuild?

Tom


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.
  2009-03-02  0:55 ` Tom Tromey
@ 2009-03-02  0:58   ` Doug Evans
  2009-03-02  1:06     ` Tom Tromey
  0 siblings, 1 reply; 6+ messages in thread
From: Doug Evans @ 2009-03-02  0:58 UTC (permalink / raw)
  To: tromey; +Cc: gdb-patches

On Sun, Mar 1, 2009 at 4:54 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> Otherwise when something gets moved then dependencies still refer to
> Doug> the old place and require the equivalent of a "make distclean"
> Doug> to get make working again (which is a bit heavyweight).
>
> Could you expand a bit on exactly what fails?  Do you see an error?  A
> missed rebuild?
>
> Tom
>

Do a "cd src/gdb && cvs update -dP" and see for yourself.   1/2 :-)

"But seriously ..."

After an update the error I see is:

make: *** No rule to make target `../../../src/gdb/signals/signals.c',
needed by `signals.o'.  Stop.

This is because signals.c has moved, but .deps/mumble still refers to
the old location.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.
  2009-03-02  0:58   ` Doug Evans
@ 2009-03-02  1:06     ` Tom Tromey
  2009-03-02 16:31       ` Doug Evans
  0 siblings, 1 reply; 6+ messages in thread
From: Tom Tromey @ 2009-03-02  1:06 UTC (permalink / raw)
  To: Doug Evans; +Cc: gdb-patches

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> make: *** No rule to make target `../../../src/gdb/signals/signals.c',
Doug> needed by `signals.o'.  Stop.
Doug> This is because signals.c has moved, but .deps/mumble still refers to
Doug> the old location.

Thanks, I see.

Your patch is ok.

It is interesting that I have never run across this particular failure
before.  This style of dependency tracking has been in use for a long
time...

I think the underlying problem is a bug in gcc.  I think -MP ought to
emit a dummy target for the primary source file as well.  I made a
note to fix this in libcpp.

Tom


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.
  2009-03-02  1:06     ` Tom Tromey
@ 2009-03-02 16:31       ` Doug Evans
  2009-03-02 17:16         ` Tom Tromey
  0 siblings, 1 reply; 6+ messages in thread
From: Doug Evans @ 2009-03-02 16:31 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches

On Sun, Mar 1, 2009 at 5:06 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> make: *** No rule to make target `../../../src/gdb/signals/signals.c',
> Doug> needed by `signals.o'.  Stop.
> Doug> This is because signals.c has moved, but .deps/mumble still refers to
> Doug> the old location.
>
> Thanks, I see.
>
> Your patch is ok.
>
> It is interesting that I have never run across this particular failure
> before.  This style of dependency tracking has been in use for a long
> time...
>
> I think the underlying problem is a bug in gcc.  I think -MP ought to
> emit a dummy target for the primary source file as well.  I made a
> note to fix this in libcpp.

I don't disagree, but it seems like .deps should be cleared out with a
"make clean" regardless.  After a configure the build directory is
clean and .deps is empty (or doesn't exist).  For consistency sake, it
makes sense to have the same after a "make clean".


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.
  2009-03-02 16:31       ` Doug Evans
@ 2009-03-02 17:16         ` Tom Tromey
  0 siblings, 0 replies; 6+ messages in thread
From: Tom Tromey @ 2009-03-02 17:16 UTC (permalink / raw)
  To: Doug Evans; +Cc: gdb-patches

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> I don't disagree, but it seems like .deps should be cleared out with a
Doug> "make clean" regardless.  After a configure the build directory is
Doug> clean and .deps is empty (or doesn't exist).  For consistency sake, it
Doug> makes sense to have the same after a "make clean".

Yeah, I agree.  In Automake we had a set of rules: if "configure" made
it, "distclean" deletes it; if "make" made it, "clean" deletes it; and
if the maintainer made it, "maintainer-clean" deletes it.

I think I got a little confused here because (IIRC) Automake arranges
for configure to make initial .Po files.  But, that's because Automake
has to work in a much less friendly environment -- it is an
implementation detail.

I still think we want to also fix this in libcpp, though, because I
think it is reasonable to use this style of dependency management, to
rename a source file, and to expect a plain "make" to just work.

Tom


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2009-03-02 17:16 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-02  0:10 [RFA] Makefile.in (clean): rm -f $(DEPDIR)/* Doug Evans
2009-03-02  0:55 ` Tom Tromey
2009-03-02  0:58   ` Doug Evans
2009-03-02  1:06     ` Tom Tromey
2009-03-02 16:31       ` Doug Evans
2009-03-02 17:16         ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox