help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Advanced auto-dependencies clarification


From: Noel Yap
Subject: Re: Advanced auto-dependencies clarification
Date: Thu, 05 Feb 2004 17:44:49 -0500

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]