This is a suggestion to consider changing the strategy on how configuration variables of the build system can be set.

Currently the TF-A build system implement a strategy where the value of configuration variables can only be set with command line parameters.
On one end this has the benefit of safety as it avoids variable name collisions in the global namespace of environment variables, but on the other end this makes life of integrators harder as it is not possible to "inject" configuration settings from "global scope".

This issue came up, in a scenario, where TF-A build is controlled by an integration system (OP-TEE makefiles), and the integration system is run by a higher layer test system. The integration system owns the TF-A configuration options which configure TF-A features. The test system owns TF-A settings related to the test environment (e.g. OPENSSL binary location). But the TF-A build system does not allow multiple owners as the parameters can only be set on the command line, which cannot be set by multiple parties. A workaround could be to enhance the integration system to allow amending TF-A parameters from higher layers, but this does not scale, as each further option owner will need interface changes.

Technical details on how TF-A build system works in this aspect.
When make starts, it duplicates all environment variables as respective make variables. The value of these variables can be overridden in the makefile, or if the makefile is written so, the values can be kept. make implements a complex priority scheme how variables get their values. (See the make documentation for details.)
In TF-A defaults.mk (and possibly other makefiles) use := operator to set default values for configuration variables. This operator will override any value mirrored from environment variables. The ?= operator in turn would keep the value already set.

Suggested actions:

• investigate risk of environment variable name collision and cost of mitigation and make a decision if a change is worth or not
• investigate which makefiles need changing
• replace := operators with ?= where needed
• this might become a significant build system interface change and a rollout plan may be needed
• roll out the changes
• have 🍺 :)