Re: Recursive make using a variable with parallel builds

[William S Fulton]

Paul D. Smith wrote:
> William S Fulton writes:
>  > The testcase below is a demonstration of a problem I've got with a much 
>  > larger build system with which I would like to start using parallel 
>  > builds. In the example below, the ok and the bad targets are essentially 
>  > the same, but the bad target uses a variable to invoke make. Why does 
>  > this variable cause a warning as shown below and how can I fix this? I'm 
>  > trying to avoid a huge rewrite by keeping the variables. The manual 
>  > indicates that $(MAKE) should be prefixed with a +, but this just causes 
>  > make to error out with:
>  > 
>  > /bin/sh: line 1: +make: command not found
>
> The manual says that the command script line should be prefixed with
> "+", not that the $(MAKE) variable needs to be so prefixed.  The "+"
> is a special character for make, just like "@" (don't print).  All
> make special characters MUST come at the beginning of the command
> script; make will NOT go searching through the entire text looking for
> a "+" or a "@" (that would be very bad).
Okay, that is much clearer for me now.

> So, if you have a rule like this:
>
>  > common_stuff = @echo bad $*; $(MAKE) $*.xtest
>
>  > %.bad:
>  >          $(common_stuff);
>
> you have to use:
>
>   common_stuff = address@hidden bad $*; $(MAKE) $*.xtest
>
> or else:
>
>  %.bad:
>           +$(common_stuff);
>
> (why do you have a semicolon here?  that will just slow make down)
Yup agreed, it is a bit of cruft left over from various modifications.

> The reason you need this in this case but not the other case is that
> if the variable $(MAKE) appears DIRECTLY in the rule text, then make
> can figure out for itself that the command invokes a sub-make.
>
> If you hide the $(MAKE) variable in another variable, as above, then
> make can't figure it out and you have to use "+" to tell it what
> you're doing.

Superb, I've got it to work in the real Makefiles too. Many thanks.

William