For patch submissions and discussion

Doug Evans | 2 Mar 2009 01:58

Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.

On Sun, Mar 1, 2009 at 4:54 PM, Tom Tromey <tromey <at> redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje <at> 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.

headers

Tom Tromey | 2 Mar 2009 02:06

Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.

>>>>> "Doug" == Doug Evans <dje <at> 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

headers

Doug Evans | 2 Mar 2009 17:31

Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.

On Sun, Mar 1, 2009 at 5:06 PM, Tom Tromey <tromey <at> redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje <at> 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".

headers

Tom Tromey | 2 Mar 2009 18:16

Re: [RFA] Makefile.in (clean): rm -f $(DEPDIR)/*.

>>>>> "Doug" == Doug Evans <dje <at> 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