decrypt.all.tool.variablesthen (remember that $* is the stem of the rule, decrypt.all.tool in this case) it extracts
target=decrypt operation=all type=tooland then it runs a make subprocess, specific to that target, type and operation. In our case, the %.variables rules is executed twice, once to build
decrypt.all.tool.variablesand once to build
libDvd.all.tool.variablesso the result is to run two separate make processes:
make internal-tool-all INTERNAL_tool_NAME=decrypt TARGET=decrypt \ _SUBPROJECTS="$(decrypt_SUBPROJECTS)" \ OBJC_FILES="$(decrypt_OBJC_FILES)" \ ... make internal-library-all INTERNAL_library_NAME=libDvd TARGET=libDvd \ _SUBPROJECTS="$(libDvd_SUBPROJECTS)" \ OBJC_FILES="$(libDvs_OBJC_FILES)" \ ...where ... stands for a lot of other variables, including all variables needed to perform the final stage: OBJC_FILES, C_FILES, JAVA_FILES, ADDITIONAL_INCLUDE_DIRS etc. Note that each make subprocess will get passed different, specific, variables. If gnustep-make wants to modify these variables in some way, it does it at this stage, before passing them to the submake process. For example, some library flags are filtered through the WHICH_LIB_SCRIPT.
What this means is that for each target/type/operation, a separate make process is run. For example, if you have two tools, decrypt and crypt, and you want to both compile and install them, it will run four make subprocesses:
make internal-tool-all INTERNAL_tool_NAME=decrypt ... make internal-tool-all INTERNAL_tool_NAME=crypt ... make internal-tool-install INTERNAL_tool_NAME=decrypt ... make internal-tool-install INTERNAL_tool_NAME=crypt ...This is the `second make invocation'. The make package knows that it is being invoked for the second time, because of the INTERNAL_tool_NAME being non-empty.