[Top][All Lists]

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

Re: Should this makefile really hang make?

From: Bryan Ischo
Subject: Re: Should this makefile really hang make?
Date: Sat, 19 Nov 2011 22:07:57 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111108 Thunderbird/8.0

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/ lib/libbar.a lib/

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

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

      ar crv $@ $^
      gcc -shared -o $@ $^

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

lib/ foo.po foo2.po

libbar.a: bar.o 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_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,

reply via email to

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