RE: auto-dep cannot possibly work?

[Paul Smith]

On Mon, 2009-11-16 at 09:33 -0800, Mark Galeck (CW) wrote:
> Well, I promised not to argue anymore about whether it is bizarre or
> not so I will have to uphold my promise unless you release me from
> it :)

If you have reasonably common situations that meet the criteria, please
do tell!

> I would still have to tell developers "if you do this bizarre thing,
> then rebuild everything", and they would have to check your IFs, let's
> say I agree with your on the number of IFs :) so they would have to
> check all your 3 IFs, and then rebuild the whole thing - that's a lot
> of work for them when they "expect" this whole thing would be taken
> care of by me.

Again, I just don't see it as a problem.  If developers are adding new
headers then surely they KNOW ALREADY the answers to these questions.
If they don't know, then how can they possibly understand what the
result of their compilation will be?!?!  I'm beginning to be very scared
when I think about your development environment.  How the heck does
anyone know what results they're going to get when the finish compiling
their code, if all these headers with the same names are being added and
removed???

> I think this is an elegant solution - notice how it not only solves
> this bizarre problem, but also notice how nicely it takes care of the
> catch-22 that happens if the user deletes include/foobar.h.

No it doesn't.  It actually CREATES a problem that is similar to, but
opposite from, the original problem you're trying to solve.

If the user deletes include/foobar.h, then you definitely DO want the
objects that depend on that file to be recompiled.  But, because your
$(wildcard ...) omitted it, make doesn't know that there's a dependency
relationship there and it won't recompile the files.

Suppose a developer wants to know, for example, which code depends on a
certain header file--one simple way is to rename the file and see what
fails to compile.  Obviously this won't work anymore.

Or, getting closer to your example, suppose there was /a/config.h
and /b/config.h and your compiler used -I/a -I/b.  Now you remove
"/a/config.h", but your objects will not recompile even though
"/b/config.h" might have totally different contents.

The traditional way of managing deleted files is much better: it will
force a recompilation if the file disappears.