> cm> TARGETLIBS = libfoo.a libfoo.so
> cm> libfoo_OBJS = foo1.o foo2.o foo3.o
> cm> libfoo_SONAMESUFFIX = .0
> cm> libfoo_SOFINALNAME = glibfoo-2.3.2.so
>
> You can do this, but not without using the new $(eval ...) function.
Ah, thank you for pointing out the eval function. I hadn't thought to
read that node before. After several passes of reading it and letting
it sink in, I think I finally understand it, and it appears the example
given addresses exactly the situation I'm in!
I rewrote the generic portions of my Makefile as follows, copying
shamlessly from the info page example:
define TARGETLIB_a_template
$(1).a : $$($(1)_OBJS)
$$(AR) rc $$@ $$^
$$(RANLIB) $$@
endef
$(foreach lib,$(filter %.a,$(TARGETLIBS)),$(eval $(call
TARGETLIB_a_template,$(basename $(lib)))))
define TARGETLIB_so_template
$(1).so : $$($(1)_OBJS)
$$(USELD) -shared $$(if $$(findstring 1,$$(LD_USECC)),-Wl$$(COMMA))[EMAIL
PROTECTED]($(1)_SONAMESUFFIX) $$< -o $$@
$$(if $$(strip $$($(1)_SOFINALNAME)),cp -af $$@ $$($(1)_SOFINALNAME),true)
$$(if $$(strip $$($(1)_SOFINALNAME)),ln -sf $$($(1)_SOFINALNAME) [EMAIL
PROTECTED]($(1)_SONAMESUFFIX),true)
endef
$(foreach lib,$(filter %.so,$(TARGETLIBS)),$(eval $(call
TARGETLIB_so_template,$(basename $(lib)))))
And that appears to work, at least with my minimal test-case setup.
Thanks!
> Note that 3.80 has a couple of bugs in the eval area. There's a beta of
> 3.81 available (see the archives for these mailing lists) which fixes
> them and is, overall, a better bet than 3.80 if you're going to use
> these expanded functions.
How do I access the archives? The page for make in the GNU free
software index listed only the mailto: address of the list, but nothing
about subscribing or accessing the archives.
Are the eval bugs you mention also described in the archives? So far,
the 3.80 release has been working fine for me, but I haven't yet tried
anything beyond this minimal test case.
> cm> And if it's performing "as expected" (this being an
> cm> unexpected/unsupported use of %), could this be taken as a feature
> cm> request to make it work as I'm attempting to use it in the next
> cm> release?
>
> No. Sometimes people want the variables/functions to be expanded before
> pattern matching, sometimes they want them to be expanded after pattern
> matching.
OK, good point. I can see how it would be just as useful in some cases
to be able to put %-patterns in variable definitions that get expanded
and then pattern-replaced. Maybe a quick reminder of the order of
operations would be helpful to add to the static pattern rule info node?
> The way make works now is the way it has always worked, and I
> don't see enough of a reason to make this sort of backward-incompatible
> change to its behavior.
Another good point. I hadn't realized static pattern rules had been
around for so long; somehow this is the first time I've run across them.
Thanks again!
Carl Miller
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
