RE: auto-dep cannot possibly work?

[Mark Galeck (CW)]

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

>If you have reasonably common situations that meet the criteria, please
do tell!

OK here we go.  What happens with that example that I showed, is 
"encapsulation".  /include/config.h does not "interface" with foobar.c directly 
- its purpose it only to interface correctly with other files in its directory, 
such as /include/foobar.h.  

Then /include1/config.h , interfaces with /include/foobar1.h

As long as they both interface correctly, then foobar.c, which has to interface 
correctly with foobar.h and foobar1.h, will work too.  

The purpose of copying.h is so that a better implementation of the interface to 
the other header files, can be done in /include1.

In fact, with this setup, foobar.c will include _both_ foobar.h files, not one. 
 And indeed, when I look at these things, they have modified multiple-include 
guards, like

#if !defined _include_config_h_
#define...

Of course, this means to avoid conflicts, one has to extensively change the new 
foobar.h.  But those changes only affect what happens with the interface to the 
other files in that directory.  

Anyway, this is what I see done here, and, while personally I would not have 2 
source files with the same name, I see it done.  In fact, my boss just came by, 
I explained the situation to him.  Everybody here, up to the highest 
management, is C-proficient.  I said, here's an interview question you can use 
"you have an application, you are not allowed to touch existing source files, 
or existing included files, or existing build commands, how can you get the 
application out of date where it has to be rebuilt?".  He was very pleased with 
the question and answer, and he said "definitely fix this, this is not an 
uncommon situation".  


> If developers are adding new
headers then surely they KNOW ALREADY the answers to these questions.


I agree with you, OK, they already know, right.  So don't worry, they know what 
they are doing.  So then I would just have to tell them, this would be a 
problem case, do rebuild it in that case.  It's just, well, they forget, and if 
I take care of this, they won't have to remember.  


>If the user deletes include/foobar.h, then you definitely DO want the
objects that depend on that file to be recompiled.  But, because your
$(wildcard ...) omitted it, make doesn't know that there's a dependency
relationship there and it won't recompile the files.

Hmm, perhaps I did not explain myself carefully enough.  The dependencies are 
generated, following the scheme from the GNU manual and other sources, when the 
.o file is built, to be used next time the question comes up whether the .o 
needs to be rebuilt.  

If between those two times the user deletes (or renames) a header file 
include/foobar.h, make still thinks include/foobar.h is a target, because it 
still has the "basic" dependency line

foobar.o: include/foobar.h

However, the "auxilliary dependency" line

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

whether the wildcard function returns an empty list or not, in either case, 
this line ensures that make will not complain that there is no way to rebuild 
the target include/foobar.h.

And then, when foobar.o is rebuilt, include/foobar.h vanishes completely from 
the makefile, and possibly, some new header files from the former wildcard 
list, may now appear in the basic lines (and in turn, depending on them, there 
may be more "potential" header files appearing on the "auxiliary lines").  And 
so forth.  

>The traditional way of managing deleted files is much better: it will
force a recompilation if the file disappears.

Yes the traditional way, is actually close to what I did above.  The 
traditional way, as explained in the well-known article, that I think you or 
others here, recommended to me: http://make.paulandlesley.org/autodep.html

It is as I do above, except without the wildcard list of potential files - with 
empty prerequisites list.  My method adds the fix the "bizarre" problem, as 
well as preserves the original method of dealing with deleted files.  I checked 
it works, but of course, maybe I missed some another "weird" case where it does 
not work...   Please tell me 

Mark