[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Static Rules Unceremoniously Dropped
From: |
Martin Dorey |
Subject: |
RE: Static Rules Unceremoniously Dropped |
Date: |
Tue, 31 Jan 2006 14:44:12 -0800 |
(
As documented in info make, 10.5.1:
`%' in a prerequisite of a pattern rule stands for the same stem
that was matched by the `%' in the target. In order for the pattern
rule to apply, its target pattern must match the file name under
consideration, and its prerequisite patterns must name files that exist
or can be made.
)
-------------------------------------
Martin's Outlook, BlueArc Engineering
-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of Paul
D. Smith
Sent: Tuesday, January 31, 2006 14:35
To: William Ahern
Cc: address@hidden; address@hidden
Subject: Re: Static Rules Unceremoniously Dropped
%% William Ahern <address@hidden> writes:
wa> Using 3.81beta3, it seems that one of our pattern rules
wa> CFLAGS_$(d) := -DFOO
wa> $(d)/%.o: $(d)/%.c -lfoo -lbar
wa> $(CC) $(CFLAGS_$(@D)) ...
wa> is dropped without notice when -lbar is not found. Note that
wa> LIBPATTERNS is nullified, and -lfoo and -lbar are explicit
wa> .INTERMEDIATE targets (or are supposed to be when they're
wa> present).
wa> Then, the default %.o: %.c rule matches, but cannot properly
wa> compile the source because of missing CFLAGS.
wa> This seems like a bug, because there is absolsutely no notice that
wa> the rule was dropped or the dependency could not be found. Maybe
wa> this issue rises from LIBPATTERNS code, and thus slips thru the
wa> cracks.
wa> I've moved a HUGE source tree over to a non-recursive make model.
wa> Fortunately this is the only bug we've hit so far, IIRC.
wa> I've debugged and debugged. Rest assured that $(d) is defined
wa> correctly, etc, etc. The only way to trigger it is to remove the
wa> rule definition for -lbar.
I'm not exactly sure what you want make to do here. As far as I can
understand from your explanation, the pattern rule wasn't dropped.
Rather, a pattern rule matches only if all the prerequisites either
exist or can be created. If one or more don't, then the pattern rule
doesn't match and make looks for another pattern rule that does work.
If one of the prerequisites is an explicit file (not a pattern) then
that file still has to either exist or be creatable by make.
Make doesn't report every pattern rule that does not match; that would
generate a LOT of useless output. If you use -d you should see it try
and discard that pattern because -lbar doesn't exist and make doesn't
know how to create it.
--
------------------------------------------------------------------------
-------
Paul D. Smith <address@hidden> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad
Scientist
_______________________________________________
Bug-make mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-make