Hi David, well yes I hope we are all friends and all that, never intended otherwise, and apologize if I made a different impression.
Yes, to your comment on depending on directories, yes I understand it, but the way people (developers) understand make, is that it depends on files not directories, if I made it otherwise, they will rise against me! For not being able to trash their development directories with temporary files. If, following your suggestion, I have a separate directory with symlinks, then I will have to tell them, that when they create a new header file, they will have to put a link to it in the symlinks directory, not to mention, that the "bizarre" case that we started with, won't work with single directory, because it is the same file name as another file. So, I would have to have a duplicate dir structure in my symlinks. People will not follow that. OK, ultimately I think it is not make's job to find out new header files that were added, even when auto-dependencies are generated. This is also an answer to Mike Shal recent question of why I thought so. I think this way now, because I realize, that the developer ought to treat makefiles as "source files" just like any other. They know to do that. They know, that this "source file" has to know about all header files for example, if it is to deal with dependencies. So they better realize, that if they add a new header file, they need to tell make about it, by editing some makefile (like a dependency makefile even if auto-generated), or by doing make clean and make again. The developer knows (they better ) that make has a picture of what object files, depend on which known source files, so naturally, if they add a new source file, make does not automatically know about it. (even if sometimes, by accident, it does, like if you add a new .c file, with the same name as existing one, earlier in vpath) Mark _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
