Robert Mecklenburg wrote: > > Paul, on your web page describing advanced auto-dependencies you > remark that one disadvantage of the "include foo.d" approach is: > > "The third problem is more serious: if you remove or rename a > prerequisite file (say a C .h file), make will stop with a fatal > error, complaining that the target doesn't exist: > > make: *** No rule to make target `bar.h', needed by `foo.P'. Stop. > > This is because the .P file has a dependency on a file make can't > find. It can't rebuild the .P file until all the prerequisites are > there, and it won't realize it doesn't need the prerequisite until it > rebuilds the .P file. Catch-22." > > I believe this explanation assumes that the .P file (with the original > name) for the renamed/removed source is still included by make. > Correct? I ask because just a few lines earlier the article provides > an example: > > SRCS = foo.c bar.c ... > ... > include $(SRCS:.c=.P) > > that, I believe, does not suffer from this problem. That is, if the > source file is renamed in or removed from SRCS, then make would not > include the file and the stop error would not occur. Correct?
I'm not Paul but I'll take a stab at this one ;-) What you say is true for the .P corresponding to the .c that was taken out of SRCS, but what about the situation in which a header file was removed. I think the article you site is a little out-dated since Paul has another article that describes the workaround (discovered by Tom Tromey) for this -- create an empty dependency rule for header files within the .P. The article can be found at http://make.paulandlesley.org/autodep.html. HTH, Noel -- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited. _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
