Re: Evaluating a variable only once after a recipe has run

[R. Diez]

First of all, thanks for the quick response.

> That's typically the job of a configure script. A configure
> script can rely on special targets in the Makefile for doing some of
> its probing. It deposits its results in an include makefile
> like "config.make".

I am afraid that this does not really cut it, at least in big, real-life 
projects.

That actually means that all such projects need a previous step in another scripting language, like a configuration script. But in this particular 
example with OpenWrt, building a cross-compilation toolchain is not the first step, but it is already midway in the makefile. So it is not like a 
top-level script could run the makefile for some special targets to do the probing. It needs to run half of the makefile to get there.

The OpenWrt build system downloads and builds many other tools, including tools for the host which do not depend on the cross-compilation target. If 
we could break the build system into 2 separate steps, then you could no longer take full advantage of parallelism: the 1st step must complete before 
the 2nd step.

It is a shame that the variable evaluation I need is not possible in GNU Make.


> Instead of trying to uses the execution of a target recipe to try to
> calculate this optimized variable (which isn't how make works,
> and will likely be fruitless) you can calculate it using a conditional
> expression which looks for the presence of that target in $(MAKECMDGOALS).
>
>    THAT_VAR := $(if $(filter that-target,$(MAKECMDGOALS)),$(shell ...))
>
> In fact MAKECMDGOALS can even be tested with ifeq/ifneq to conditionally
> include makefile text:
>
>    ifneq($(filter that-target,$(MAKECMDGOALS)),)
>    # chunk of makefile syntax here
>    THAT_VAR := $(subst ... $(shell ...))
>    endif


That does not cut it either, I'm afraid. Say that the makefile has already run the cross-compiler recipe. The next invocation may not request it as a 
goal any more. The variable is not actually needed for the cross-compiler recipe, but for all targets that depend on it. The variable's definition 
uses the cross-compiler, but any other target later one may use that variable.

I would have to filter for any target that ultimately depends on the 
cross-compiler target, and that is not really feasible.

Best regards,
  rdiez