Are nested macros supported?

[markand]

Hi,

I must say I'm not sure if it is really valid in POSIX because the spec does not mention nested macros. Both GNU and BSD make variants support this. I must say this is handy to provide some kind of per-target variables:

.POSIX:

.c:
    echo "CCLD $@ with $($(@F)_LIBS)"
    $(CC) -o $@ $< $($(@F)_LIBS) $(LDFLAGS)

foo=            foo
foo_LIBS=       -lm

all: $(foo)

To test, just create a dummy main in foo.c

GNU Make (4.3)

$ make 
echo "CCLD foo with -lm"
CCLD foo with -lm
c99 -o foo foo.c -lm 

BSD make

$ bmake
echo "CCLD foo with -lm"
CCLD foo with -lm
c99 -o foo foo.c -lm 

pdpmake (3db377e12759c279781eed32730fca8d6ea0e002)

$ pdpmake  
echo "CCLD foo with "
CCLD foo with 
c99 -o foo foo.c  
pdpmake: nothing to be done for all

[rmyorston]

Nested macros aren't supported in POSIX mode. The standard says:

If string1 in a macro expansion contains a macro expansion, the results are unspecified.

There is a defect report suggesting nested macros should be allowed but it's currently still open.

pdpmake supports nested macros as a non-POSIX extension.

[Earnestly]

But that's in reference to string1 = [string2], in construction of the macro itself. What @markland is doing is arguably the same as seen in conditional macros that exploit this fact by using $(conditional_$(bool)) during expansion.

However it does also mention that string1 resolving to a macro is "unspecified" but I'm not sure how the form of string1 = [string2] relates to macros that are expanded in commands and elsewhere.

PS: I do conceed that the austinbugs is a lot clearer and does make it pretty explicit.

[rmyorston]

string1 is overloaded in the section on macros. The instance of string1 I referenced is in relation to macro expansion.

[Earnestly]

Then it is indeed unspecified, that's unfortunate

[markand]

Yeah and without activity in 12 years I'm not sure we will get any news on it :(