On master (1e7564eca8a688f39c75540877ec3bdfdde766b1) the depends build system, which is based on pure GNU Make, works, but it lacks robustness, and in some corner cases it fails. For example, see bitcoin/bitcoin#22552.
Another bug in the depends build system has already become a problem at least two times in the past (https://github.com/bitcoin/bitcoin/pull/16883#issuecomment-683817472 and #24134). Each time the problem was solved with other means.
The initial solution had some discussion. Also it was discussed on the IRC meeting in #bitcoin-core-builds channel. This PR, actually, is a resurrection of it, as the bug silently struck pretty recently.
The bug is well described in bitcoin/bitcoin#22719.
Here is another, a bit simpler description, which requires only basic shell (bash, dash etc) experience.
After creating targets by this code:https://github.com/bitcoin/bitcoin/blob/1e7564eca8a688f39c75540877ec3bdfdde766b1/depends/funcs.mk#L280 a "draft" line of recipe like $($(1)_config_env) $(call $(1)_config_cmds, $(1)) becomes a shell command sequence VAR1=foo VAR2=bar command1 && command2 which is supposed to be executed in a new sub-shell.
Please note that VAR1=foo VAR2=bar part is visible for the first command1 only (for details see shell docs). Example:
$ VAR1="foo" VAR2="bar" echo "begin" && printenv VAR1 && printenv VAR2 && echo "end"
begin
$ echo $?
1
Using the export command is a trivial solution:
$ export VAR1="foo" VAR2="bar"; echo "begin" && printenv VAR1 && printenv VAR2 && echo "end"
begin
foo
bar
end
$ echo $?
0
As a new sub-shell is invoked for each line of the recipe, there are no side effects of using export. It means this solution should not be considered invasive.
Fixes bitcoin/bitcoin#22719.
Also this PR removes no longer needed crutch from qt.mk.
