* [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