Followup...

> 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}.

I've confirmed this.  Though I didn't think % would be accepted as a valid
character in a variable name, I actually was able to set

%_OBJS = foo1.o foo2.o foo3.o

and have those three files show up properly as the prerequisites to
libfoo.a with the rule

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


After going back and reviewing the info page for GNU make further, I came
up with another approach.  I attempted to write the rule using a fixed
variable name that's given a target-specific definition.  The shared portion
of my Makefile now reads:

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

$(filter %.so,$(TARGETLIBS)) : %.so : $(TARGETLIB_OBJS)
        $(USELD) -shared $(if $(findstring 1,$(LD_USECC)),-Wl$(COMMA))[EMAIL 
PROTECTED]($*_SONAMESUFFIX) $< -o $@
        $(if $(strip $($*_SOFINALNAME)),cp -af $@ $($*_SOFINALNAME),true)
        $(if $(strip $($*_SOFINALNAME)),ln -sf $($*_SOFINALNAME) [EMAIL 
PROTECTED]($*_SONAMESUFFIX),true)

and the project/directory specific portion, for my example, reads:

libfoo_OBJS = foo1.o foo2.o foo3.o
libfoo.a libfoo.so : TARGETLIB_OBJS = $(libfoo_OBJS)


This doesn't appear to work, either.  Running "make -p" shows:

# makefile (from `Makefile', line 20)
libfoo_OBJS = foo1.o foo2.o foo3.o

under Variables and:

libfoo.a:
#  Implicit rule search has not been done.
#  Implicit/static pattern stem: `libfoo'
#  Last modified 2004-03-10 18:22:42
#  File has been updated.
#  Successfully updated.
# makefile (from `Makefile', line 21)
# TARGETLIB_OBJS = $(libfoo_OBJS)
# variable set hash-table stats:
# Load=1/32=3%, Rehash=0, Collisions=0/1=0%
#  commands to execute (from `../../../Rules.mk', line 111):
        $(AR) rc $@ $^
        $(RANLIB) $@
        
under Files, with an analagous entry for libfoo.so (omitted for brevity).

But neither libfoo.a nor libfoo.so seem to end up having any prerequisites.
I'm guessing the target-specific variable declaration takes effect only in
the actual commands used to build that target, and not in the prerequisites
list of the rule.

Again, 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" (it's not expected that
target-specific varaible definitions are available in the prerequisites
list for that target), 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

Reply via email to