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