>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 _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
