RE: auto-dep cannot possibly work?

[Paul Smith]

On Sat, 2009-11-14 at 20:48 -0800, Mark Galeck (CW) wrote:
> >I think your conclusions are a little strong here.
> 
> Well yes, I am a perfectionist :)  if a tool has a bug, even the
> smallest one, that cannot be fixed withing the realm of that tool,
> then I say it is a flawed tool.  

*shrug* you must be burdened with lot of disappointment in your tools.

> >Yes, it's true that IF someone adds a new header file that has the same
> name as an existing header file, and IF that new header file appears in
> a directory that is before the existing header directory on the -I list
> for the compiler, and IF the addition of that header file does not
> require the source file or any other header file that the source file
> includes to be modified (and hence rebuilt), 
> 
> Your third "IF" is automatically satisfied upon the first two.  So
> only the first two IFs would have to happen.

Not true.  Since it's a "negative IF" then yes, if it doesn't happen
then the problem occurs.  But if it does happen, then the problem
doesn't occur.

Normally if someone adds a new header to a build system, it's because
there is new or different functionality that they are trying to create,
not just for the joy of using their source code control tool.  If you're
adding a file that mimics another file there's a reasonable chance that
source files that included the original need to be modified to behave as
desired when they include the new file.  Or, perhaps the original file
needs to be modified to distinguish it from the new one.  If they are
modified, the targets that rely on them will be rebuilt anyway (due to
this change) and there is no problem.

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.

> Paul, I thought some more here and looked at our code, and in fact, I
> beg your pardon, this is not "extremely unusual" but quite common in
> fact!  There are lots of header files with the same name, like
> "config.h", or "includes.h" (which just lists other include files).

If your development model has lots of headers like "config.h" or
"includes.h" all with the same names being defined all over the source
code tree with no real controls over where and how they might be
included, then I think you have much more serious problems than worrying
about this corner case in make behavior.  How can anyone ever know what
file IS ACTUALLY being used by the compiler, never mind make?  You must
be constantly running the preprocessor just to know what's being
included.  That's simply a disaster.

Why not suggest to your development team that they come up with a decent
file naming convention?  That would solve this problem (and probably
others) much more elegantly.

> Developers are apt to add more.  If they do, the first IF is
> satisfied, and if you think about it for a moment, you will realize
> that is very very hard to check the second IF, because there could be
> things like #include "../../config.h"

This is because you've chosen to throw away the paths and go with just
simple filenames.  I would never do that.  I always use fully-qualified
paths in my deps files.  If you do that, there is no confusion.

Another reason the vpath solution is not ideal is that it's common to
have different source files use different -I flags, while VPATH is for
all files.  This can lead to make choosing the wrong header.

> Essentially, every time somebody adds another header file (which
> happens all the time),  I have to tell them:  
> 
> "if you add a header file, check if there is already another one with
> the same name elsewhere in the system, and if so, the dependencies
> will not work and you have to rebuild the whole thing"

You are simply making the problem larger than it really is.  What you've
said here is NOT TRUE.  The mere existence of another header file
somewhere in the system, by itself, doesn't hurt anything.

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).

The only way you get a problem is if all these different items are
satisfied.

In my opinion (c) and (d) together, in particular, is unlikely.  Why
would you add a new header that had the same name, was earlier in the
include paths, and didn't require any changes to existing source code or
header files?

But if such a bizarre situation DID occur, then you would need to
recommend that people run "make clean" or similar to rebuild their
dependencies.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.net
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist