Re: auto-dep cannot possibly work?

[Mike Shal]

Hi all,

On 11/15/09, Paul Smith <address@hidden> wrote:
>  I'll say it again, slightly differently: this problem only happens if
>  you (a) add a new header, that (b) has the same name as an existing
>  header, and (c) appears earlier in the include list than the existing
>  header, and (d) does not require any other changes to headers or source
>  code that include the existing header.  In that situation, then make
>  will fail to rebuild the object file when it should.  If any one of
>  those items is not satisfied, then make will behave correctly.

I'll also say this slightly differently :)... which of these doesn't belong?

a) you regularly add new header files
b) you may name header files with the same name as existing headers
c) you may put a header file with the same name earlier in the include path
d) you should know what existing source/header files need to be
modified because of the new header file

And the answer is...

d! How the heck should you or I know what files need to be modified
just because a new header was added? That's the build system's job. I
may be a newbie to some large software project, and not know every
file inside and out. Keep in mind you might not even be the one who
actually added the header - it could be pulled in from a version
control update.

Looking at your example in more detail...

>  Let's look at it.  Suppose you have a file foo.c that #includes
>  "config.h".  Your compiler lists "-I/a -I/b -I/c" on the compile line.
>  The header "config.h" lives in "/b".  There is no "config.h" in "/a" or
>  "/c".
>
>  Now you run make and it generates a dep file something like this:
>
>         foo.o: foo.c /b/config.h
>
>  Fine.  Now someone adds a new header file.  Going by my items above (a)
>  is satisfied (a new header exists).  For (b), if the new header is named
>  "/a/cfg.h" then obviously there's no problem: make won't, and shouldn't,
>  rebuild foo.o.  For (c), if the new header is "/c/config.h", then
>  there's no problem either: make won't rebuild foo.o, but it SHOULDN'T
>  rebuild foo.o because foo.o doesn't depend on /c/config.h--by the
>  include paths /b/config.h will be found first and /c/config.h is not
>  relevant.  For (d), if "/a/config.h" is added and that means that some
>  change is needed in either foo.c or /b/config.h, then foo.o will be
>  recompiled ANYWAY since one of its prerequisites was changed, then the
>  next time you run make it will have the right dependencies (since the
>  compiler will generate the new list showing "/a/config.h" as the
>  prereq).

I agree with (a), (b), and (c). That all sounds perfectly reasonable.
But for (d), I don't buy the argument that "if a/config.h is added and
that means that some change is needed in either foo.c or /b/config.h".
While it may be true that some change is needed, how do I know that?
It's easy to see in this case because there's 3 files. If there's
hundreds or thousands, how would I know that some random C file
somewhere else entirely needs to be edited? Ideally the build system
would rebuild it, and then I'd get an error because I'm now using a
different header. Worst case is the build *looks* like it succeeds and
you end up checking in your change, and the next poor shlub who does a
clean checkout has to find the mess.

Mark, I applaud your goal of trying to get make to behave properly in
all cases. However, once you have the -I paths knocked out, does your
approach also work for -L and libraries? What about for programs that
aren't gcc? What happens when you have a Makefile that builds
libfoo.a, but you realize 'foo' is already trademarked so you change
it to 'libbar.a'? Will all those other Makefiles that still reference
libfoo.a report an error? Or will it silently succeed because libfoo.a
still exists in the filesystem, and once again leave the mess for the
next clean build?

Maybe you already have answers to these scenarios, in which case I can
come up with more :)

-Mike