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