RE: auto-dep cannot possibly work?

[Mark Galeck (CW)]

>So the "solution" I settled on, is, I checked, that currently in our system no 
>file depends on two include files with the same name.  Then I will not use 
>full-path include dependencies, but only file names:
foobar.o:  foobar.h foo.h
Then vpath is split off into a separate makefile, included in the main one.  
And the developers are reminded, that it is their responsibility, if they make 
a new directory, to update -INCLUDE options as needed, and the file with vpath 
directives, one of them being 
vpath %.h 
-------------------


Well no, of course I was wrong, there are in fact lots of cases where one 
source depends on multiple includes with the same names.  So that "solution" is 
not.  


But, here is a good try, I think.    Earlier today I asked a silly question 
about ignoring a nonexistent target completely.  Well, it's easy (see below).  


So, the full solution to the dependency problem, would be, 

if a source foobar.c has #include "../include/foobar.h", then do not just do 
something like:

foobar.o:  ../include/foobar.h


but add the following.  When you generate your dependencies (at the previous 
build), collect all the include files, and have a Perl script that generates 
header files full paths, with same names as existing include files, that could 
potentially land in the compiler search path.  

If one such file is:  ../include1/foobar.h

then add this:

ifneq (,$(wildcard ../include1/foobar.h))
../include/foobar.h:  ../include1/foobar.h
else
../include/foobar.h:
endif

----------------------

Great, right?  Next time we run make, it finds out if such offending new header 
file, with the same name as an old one, and potentially in the search path, 
exists, if so, we depend everything on it, that already depended on the old 
header file.  And then after we remake foobar.o, include1/foobar.h may or may 
not be in the dependency list (depending on whether it was actually in the 
search path for the compiler).  If the file does not exist, nothing happens.  

OK, there is one problem!  What if a particularly clever developer, decides to 
not "copy" or make a new file with the same name as the old one "foobar.h".  
But instead, if he does 

>mv include1/foo.h include1/foobar.h

Now we are still in trouble.  Because the timestamp for foobar.h, created this 
way, would be as old as foo.h.  And so yes make will notice that the new 
foobar.h is there, but will think it  is an old file, older than 
include/foobar.h, and now again foobar.o will not be rebuilt.  

Anybody knows what to do about this??