RE: auto-dep cannot possibly work?

[Mark Galeck (CW)]

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


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.  


So instead, the solution I have is, to add to the original dependencies, as 
explained in the GNU make manual, the ones of the following kind:

include/foobar.h:  $(wildcard include1/foobar.h include2/foobar.h ...)

where the files in the wildcard, are all the potential include files, with the 
same name foobar.h, that, if present, would go before the target 
/include/foobar.h in the compiler search path.  

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.  

Please anybody tell me if you see any problem with this.  (Of course, one needs 
to generate the list of potential include files, which is a substantial Perl 
program, and I am working on it now).  

Otherwise, in my humble opinion, it would be good to mention this in the 
section: "Generating Prerequisites Automatically" of the GNU manual, since it 
not only solves the bizarre problem, but also the less bizarre one of deleting 
a header file.  


>So, they are going to add a new header file to this directory.  Now
EVERY source file that used to include /include1/config.h, and worked
fine and expected that, will start using /include/config.h the next time
it's compiled.

>And that's OK?  Not a problem?  No other changes need to be made to the
source code?  It just seems unlikely to me.