inline python-for-build wrapper generation

[jjhelmus]

Generate the python-for-build wrapper build-cpython.sh using a Makefile fragment to avoid patching CPython. This functionality is only used post-install. It is not needed during the build.

closes #959

[zanieb]

Why is this better?

[jjhelmus]

The primary benefit of this change is to the patches which modify Makefile.pre.in while maintaining the same functionality. This patch has a small maintenance burden since it may need to be updated when upstream changes Makefile.pre.in.

Additionally, since this wrapper is unique to python-build-standalone there is no need to upstream it. Removing the patch make this clear (?). The wrapper is only used after CPython is built and installed, it is a post-build requirement when cross-compiling.

I would not consider this change critical. If the patch is more clear this should not be merged.

[zanieb]

Perhaps we should back up a little, what is this for?

[jjhelmus]

After building and installing CPython, an interpreter is needed to:

• Install pip, and setuptools for Python 3.10/3.11.
• Modify sysconfig.
• Generate metadata for PYTHON.json.
• Update shebang lines.

In a native build, the newly installed Python interpreter can be used for these tasks.

When cross-compiling, the new interpreter targets a different architecture and may not run on the build system (for example, a RISC-V interpreter on an x86-64 host). CPython handles this during the build using the PYTHON_FOR_BUILD Make variable, which invokes the host interpreter with the target environment, including sysconfig, platform tags, and ABI flags.

The previous patches, and now the inline Makefile snippet, create a python-for-build wrapper from the expanded PYTHON_FOR_BUILD value so the same environment can be used for the post-install tasks. Running the host interpreter directly would select incorrect paths, platform tags, ABI flags, and other target-specific configuration.

[zanieb]

Why is this only useful to us and not other redistributors?

[jjhelmus]

Why is this only useful to us and not other redistributors?

I was just writing this up 😄

There is also an argument for this wrapper to be upstreamed to CPython as other projects that do cross-builds and then run Python tooling against the the target install would benefit from this wrapper. That said, this is a narrow use-case which may not warrant upstream-support.

[jjhelmus]

This change is not tied to upstreaming the patch. The addition can be done even if the project no longer carries the patch but rather introduces the wrapper via a Makefile snippet.

[zanieb]

I don't find the logic here very compelling