Re: make: ignore stale .depend

["Simon J. Gerraty" <sjg%crufty.net@localhost>]

On Sun, 28 Nov 2010 03:50:29 +0000, David Holland writes:
>That is, suppose you have ../foo/foo.c that uses ../foo/foo.h and
>../include/stupid.h, and stupid.h gets removed. Now, if foo.d does
>*not* depend on stupid.h, you lose if include statements in stupid.h
>change. So somewhere you must have
>
>   foo.d: ../foo/foo.c ../foo/foo.h ../include/stupid.h
>
>and (in the absence of either special hacks or further refinement) if
>you remove stupid.h this will not rebuild foo.d but instead fail with
>"make: don't know how to make ../include/stupid.h".

Unless you tag ../include/stupid.h as .OPTIONAL

>for regenerating stupid.h. This will be fairly delicate to implement
>correctly, especially with the mess make currently is inside. :(

I agree that would be a challenge to fix, and I'm pretty certain
that I'd never have the time or energy to do it.

> > As I've noted before, generating that data as a side effect of
> > compilation mitgates a lot of the issues.
>
>No, on the contrary I'd say it doesn't, and in fact this problem only
>appears when you try to do depends automatically. If you have manual

No, the problem appears with 'make depend' too, as demonstrated.

>depends, removing stupid.h will cause "don't know how to make
>stupid.h" but then you just make depend and all is henceforth well.

Only if you fix bsd.dep.mk, so that 'make depend' actually does
something in this case.  Today it does nothing, because foo.d is up to
date wrt the explicit sources.

>It's when you try to do it automatically that make ends up unable to
>proceed because it can't regenerate stupid.h.

Except that the FROM_DEPEND hack, means that stupid.h isn't a problem.
The build proceeds, the dependencies are automatically updated and life
goes on.

> > This problem is also pretty much solved in meta mode.
>
>I'm not convinced that meta mode is (or can be) any different than gcc
>-MD for these purposes; all it can do is record which files were read
>during compilation, which leads to the same problem if one of them
>disappears later.

It has no problem in that regard.  The difference being that the
function which processes a .meta file, is fully aware that it is
captured data, and does not try to create dependencies for any of it.
It just notes that "a file we used last time is newer or missing; out-of-date"

> > The current FROM_DEPEND etc flag at least allows make to discount such
> > dependencies. 
>
>Yes, but can we please make it an explicit attribute instead of a
>special-case hack for .depend? That is, something like

.OPTIONAL already exists for this.

>
>   .MISSING: ../foo/foo.c ../foo/foo.h ../include/stupid.h
>
>which mkdep can easily put into the .d and/or .depend files.

Which is great, but what about gcc -M?
Note my autodep.mk, did at one point go to great lengths to add
.OPTIONAL to all the dependencies
but it was complex, and didn't seem to help - so was removed.

>Of course it doesn't count, but what about making it an explicit
>attribute?

As noted, it already, exists but requires the tool that generates
.depend play along.

The FROM_DEPEND thing could probably have been done by simply adding
OP_OPTIONAL don't know why it wasn't.

Anyway re-writing make might solve all the problems, but numerous people
have attempted it - none successfully AFAIK, and until someone does one
which is as capable as our make, I'm not interested.

Thanks
--sjg