Re: Should this makefile really hang make?

[Bryan Ischo]

On 11/19/11 16:25, Paul Smith wrote:
> Gak.  This is a big mess.  Handling of : and % in second expansion
> situations is very tricky.

I'm sure I must be thinking about it in too simplistic a manner because 
it doesn't seem that complex to me.

I thought that the first 'expansion' was simply the resolution of all 
variable references, so that, e.g.

%.a: $$($(SRCDIR)/$$@:%.a=%.c)

Would, by first expansion, result in:

%.a: $(foo/bar/$@:%.a=%.c)

(if SRCDIR == foo/bar)

Then the second expansion would have access to the automatic variables 
of the rule, so $@ would be meaningful, and the result of that second 
expansion would treat the substitution pattern as it would in any other 
substitution pattern variable reference.

I don't quite see why the substitution pattern is being interpreted 
until the substitution of the variable including the substitution 
pattern is done, and that doesn't happen until the second expansion.

> Maybe we need to allow escaping of "%"; something like:
>
>    %.a: $$(patsubst \%.a,\%.o,$$@)
>
> These areas need more consideration, to be sure.

Possibly.  I certainly appreciate your effort in diagnosing this issue 
and would be willing to support whatever resolution you think is best. I 
personally have backed off of using SECONDEXPANSION; I had not realized 
previously that I could just do something like this:

all: lib/libfoo.a lib/libfoo.so lib/libbar.a lib/libbar.so

%.o: %.c
      gcc -o %@ -c $^

%.po: %.c
      gcc -fPIC -o %@ -c $^

%.a:
      ar crv $@ $^

%.so:
      gcc -shared -o $@ $^

lib/libfoo.a: foo.o foo2.o

lib/libfoo.so: foo.po foo2.po

libbar.a: bar.o

libbar.so: bar.po

In other words, I didn't realize that I could create pattern rules 
without any prerequisites defined and then define the prerequisites 
later when I define the specific target.  This works just fine for my 
purposes without using funky computed variable names as I had been 
trying to do with SECONDEXPANSION.  I don't like having to repeat the 
object file names for the static and shared versions of the library, but 
I can get around that with something like this:

libfoo_OBJECTS := foo.o foo2.o

lib/libfoo.a: $(libfoo_OBJECTS)

lib/libfoo.so: $(libfoo_OBJECTS:%.o=%.po)

It would be a little nicer to have the shared object library handled 
"automatically" as I had with my SECONDEXPANSION version but it is not 
the most important thing.

I just wanted you to know that there is no urgency for me with respect 
to fixing the SECONDEXPANSION behavior; but I certainly do appreciate 
your efforts in that direction and would be happy to offer any help I can.

Best wishes,
Bryan