RE: auto-dep cannot possibly work?

[Mark Galeck (CW)]

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

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

>In real life, the automated dependencies do get out of sync
occasionally, and sometimes you have to regenerate them.

Well I value your opinion enormously, and, as explained above, to me if my 
auto-dependendencies "get out of sync" then that means I failed.  

>To go from an extra manual step in this extremely unusual situation to
"cannot possibly work" seems to me to be a reach.

Yes again, my point was, the automated dependencies are supposed to be 
"automated", like make in fact, is "automatic", that is the whole point of 
using it.  By "cannot possibly work" I meant simply, there is a case, however 
obscure, where the thing won't work.  

No need to argue, I see your point and I explained my point.  

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

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 

and that in particular they are responsible that the order of -INCLUDE options 
and the order of directories on vpath %.h, should be consistent in such a way, 
that the compiler and the make, will always find the same header file.  This in 
particular would mean, that the condition above, that one source does not 
depend on two different includes with the same name, is maintained.  .  I would 
not explicitly state that restriction, just let them figure it out, and hope no 
one ever complains.  

So in other words, shift the burden of maintaining consistency of vpath and -I, 
to the developer, as I think it should be.  


Mark