help-make
[Top][All Lists]
Advanced

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

Using % in a variable name as a static pattern prereq?


From: Carl Miller
Subject: Using % in a variable name as a static pattern prereq?
Date: Wed, 10 Mar 2004 15:27:33 -0800
User-agent: Mutt/1.5.5.1+cvs20040105i

Hi.  I'm using GNU make 3.80, and I've run into something that isn't
working as expected.  I'm beginning to suspect that the behavior I'm
looking for isn't supported, but I'd like confirmation on that.

I'm trying to automate building a variety of libraries by using static
pattern rules and having a variable per library to call out what .o
files should be included in each library.  The relevant portion of the
makefile is:

$(filter %.a,$(TARGETLIBS)) : %.a : $(%_OBJS) 
        $(AR) rc $@ $^
        $(RANLIB) $@

$(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) 
address@hidden($*_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




reply via email to

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