This is a variation on the change introduced by #473.
host_configure_args is defined as a class-level variable; however, there are build steps that assign this class-level instance directly to configure_cmd, and then concatenate build-specific commands. As a result, configure command line arguments can be duplicated (sometimes in contradictory ways).
I noticed this on the iOS builds; see L3 defining the args in this build - there are essentially three copies of the same command line arguments (--with-pydebug et al is defined 3 times).
However, it also impacts on any build that uses the UnixCrossBuild base class. AFAICT, the only example of a builder affected by this that is currently in use is the (now deprecated) WASI32 builders; those end up with artefacts like the --with-pydebug --without-pydebug arguments in this build log. This doesn't appear to be causing problems at present, but it is at the very least confusing.
This PR takes a copy of the class-level host_configure_args variable before modifying it, which should prevent different instance setups tainting each other. This is a pattern that is also followed by the handling of other args (e.g., defaultTestOpts and testFlags).
vstinner
commented
6 months ago
This is a variation on the change introduced by #473.
host_configure_argsis defined as a class-level variable; however, there are build steps that assign this class-level instance directly toconfigure_cmd, and then concatenate build-specific commands. As a result, configure command line arguments can be duplicated (sometimes in contradictory ways).I noticed this on the iOS builds; see L3 defining the
argsin this build - there are essentially three copies of the same command line arguments (--with-pydebuget al is defined 3 times).However, it also impacts on any build that uses the
UnixCrossBuildbase class. AFAICT, the only example of a builder affected by this that is currently in use is the (now deprecated) WASI32 builders; those end up with artefacts like the--with-pydebug --without-pydebugarguments in this build log. This doesn't appear to be causing problems at present, but it is at the very least confusing.This PR takes a copy of the class-level
host_configure_argsvariable before modifying it, which should prevent different instance setups tainting each other. This is a pattern that is also followed by the handling of other args (e.g.,defaultTestOptsandtestFlags).