>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 -------------------
Well no, of course I was wrong, there are in fact lots of cases where one source depends on multiple includes with the same names. So that "solution" is not. But, here is a good try, I think. Earlier today I asked a silly question about ignoring a nonexistent target completely. Well, it's easy (see below). So, the full solution to the dependency problem, would be, if a source foobar.c has #include "../include/foobar.h", then do not just do something like: foobar.o: ../include/foobar.h but add the following. When you generate your dependencies (at the previous build), collect all the include files, and have a Perl script that generates header files full paths, with same names as existing include files, that could potentially land in the compiler search path. If one such file is: ../include1/foobar.h then add this: ifneq (,$(wildcard ../include1/foobar.h)) ../include/foobar.h: ../include1/foobar.h else ../include/foobar.h: endif ---------------------- Great, right? Next time we run make, it finds out if such offending new header file, with the same name as an old one, and potentially in the search path, exists, if so, we depend everything on it, that already depended on the old header file. And then after we remake foobar.o, include1/foobar.h may or may not be in the dependency list (depending on whether it was actually in the search path for the compiler). If the file does not exist, nothing happens. OK, there is one problem! What if a particularly clever developer, decides to not "copy" or make a new file with the same name as the old one "foobar.h". But instead, if he does >mv include1/foo.h include1/foobar.h Now we are still in trouble. Because the timestamp for foobar.h, created this way, would be as old as foo.h. And so yes make will notice that the new foobar.h is there, but will think it is an old file, older than include/foobar.h, and now again foobar.o will not be rebuilt. Anybody knows what to do about this?? _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
