On Thu, Mar 11, 2004 at 06:05:24PM -0800, Carl Miller wrote:
>
> $(filter %.a,$(TARGETLIBS)) : %.a : $(%_OBJS)
> $(AR) rc $@ $^
> $(RANLIB) $@
Form 'info make':
Reading Makefiles | How 'make' Reads a makefile
--------------------------------------------------------------------------
Rule Definition
---------------
A rule is always expanded the same way, regardless of the form:
IMMEDIATE : IMMEDIATE ; DEFERRED
DEFERRED
That is, the target and prerequisite sections are expanded
immediately, and the commands used to construct the target are always
deferred. This general rule is true for explicit rules, pattern rules,
suffix rules, static pattern rules, and simple prerequisite definitions.
--------------------------------------------------------------------------
So you are right in your observation, you cannot use the stem in the way you try to.
In your case you have to do the $(filter ...) twice.
Sam
>
> $(filter %.so,$(TARGETLIBS)) : %.so : $(%_OBJS)
> $(USELD) -shared $(if $(findstring 1,$(LD_USECC)),-Wl$(COMMA))-soname=$@
> $($*_SONAMESUFFIX) $< -o $@
> $(if $(strip $($*_SOFINALNAME)),cp -af $@ $($*_SOFINALNAME),true)
> $(if $(strip $($*_SOFINALNAME)),ln -sf $($*_SOFINALNAME) [EMAIL
> PROTECTED]($*_SONAMESUFFIX),true)
>
>
> This portion of the makefile is shared across many projects. If a project
> wants to build libfoo.a and libfoo.so, for example, its individual makefile
> could then just define:
>
> TARGETLIBS = libfoo.a libfoo.so
> libfoo_OBJS = foo1.o foo2.o foo3.o
> libfoo_SONAMESUFFIX = .0
> libfoo_SOFINALNAME = glibfoo-2.3.2.so
>
> which keeps things nice and simple in the per-project, per-directory
> makefiles. Unfortunately, when I try this, libfoo.a and libfoo.so end
> up with no prerequisites. It appears that the % in the prerequisites
> field of the static pattern is not recognized inside a variable name.
> I suspect it's using $(%_OBJS) with a literal % in the variable name as
> the prerequisites list instead of $(libfoo_OBJS) when that rule gets
> invoked to build libfoo.{a,so}.
>
> Could anyone confirm/deny my suspicion? If it's supposed to work in
> the manner I'm trying to use it, could anyone suggest troubleshooting
> approaches? And if it's performing "as expected" (this being an
> unexpected/unsupported use of %), could this be taken as a feature
> request to make it work as I'm attempting to use it in the next release?
>
> Thanks much!
>
>
> Carl Miller
>
>
> _______________________________________________
> Bug-make mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/bug-make
--
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
