Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

$^ means dependencies of target? or current rule?

2 views
Skip to first unread message

Greg Chicares

unread,
May 19, 2000, 3:00:00 AM5/19/00
to
Does $^ mean
- all the dependencies of the *target*, or
- all the dependencies of the *rule* where it appears?

Quoting from the manual at

Section 'Features of GNU make' says
"The automatic variable $^ containing a list of all dependencies
of the current target."
but section 'Writing Shell Commands with Directory Search' says
"the value of `$^' is a list of all the dependencies of the rule"

Based on trying it with the mingw.org port of make 3.77, I suspect
it's the first. If so, I suggest that the word "rule" in the
second quotation be changed to "current target".

Here's an example.

foo.exe : bar.lib quux.def
foo.exe : DLLSPEC = -H=xyz.csm
foo.exe : $(objects)
$(TLINK32) \
$(LDFLAGS_EXE) \
$(startup_obj) \
$^, \
and so on

bar.lib has a rule elsewhere to build it
quux.def is an odd sort of source file;
it should never be rebuilt
objects is what it normally is
$^ includes bar.lib and quux.res
but I don't want it to

I got around that with $(filter-out):
$(filter-out %.def %.lib %.res, $^), \

Is there a better way?

I think double-colon rules are out,
because I want the target-specific
assignment of DLLSPEC whenever this
target is built.

Paul D. Smith

unread,
May 20, 2000, 3:00:00 AM5/20/00
to
%% Greg Chicares <chic...@mindspring.com> writes:

gc> Does $^ mean
gc> - all the dependencies of the *target*, or

Yes.

gc> - all the dependencies of the *rule* where it appears?

No.

gc> Based on trying it with the mingw.org port of make 3.77, I suspect
gc> it's the first. If so, I suggest that the word "rule" in the
gc> second quotation be changed to "current target".

OK.

gc> I got around that with $(filter-out):
gc> $(filter-out %.def %.lib %.res, $^), \

gc> Is there a better way?

If all your objects in in .o (or .obj) it might be simpler to use:

$(filter %.obj,$^)

Other than that, no, there's no better way.

gc> I think double-colon rules are out,
gc> because I want the target-specific
gc> assignment of DLLSPEC whenever this
gc> target is built.

Double-colon rules won't do what you want, because if it has
prerequisites than only the particular commands associated with the
out-of-date target are rebuilt.

--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.

0 new messages