From a pure configuration perspective, this seems a fairly straightforward.

My concern is the impact on wheels (and, for that matter, the binaries in the standard library). iOS wheels are linked against libpython because -undefined is flagged as a deprecated linker argument.

What (if any) testing have you done of this code with the standard library and/or third party libraries?

Context first: Kodi embeds Python in a single signed app binary. It has built
with --disable-shared --disable-framework since 2017, and carries a
downstream patch to get past the iOS refusal — so this PR asks upstream to
allow what that patch already does, rather than to enable something new.

The stdlib is built static (MODULE_BUILDTYPE=static), so no wheels are
involved there. Binary addon modules are a different matter: xbmc/xbmc#28808
enables AppleFrameworkLoader so they can load from <app bundle>/Frameworks,
with packaging still in progress. So a static libpython and dynamically loaded
extensions do coexist in this configuration — how those extensions resolve
their Python symbols is the part I have not verified.

Testing, honestly: I built libpython3.16.a for --host=aarch64-apple-ios12.0 --disable-shared --disable-framework and checked the configure matrix. No
extension modules, no wheels. I did verify that --enable-framework produces a
byte-identical Makefile and pyconfig.h to unpatched main, so nothing
possible today changes.

Your point about wheels stands: with no libpython dylib there is nothing for a
prebuilt wheel to link against, and -undefined dynamic_lookup is deprecated.
What would you want configure to do about that:

• document the mode as unsupported for wheels, or something stricter?

Happy to build the stdlib statically for iOS and report back if that helps.

Ran the stdlib build — you were right, this is broken as it stands.

make with --disable-shared --disable-framework fails on every shared extension module:

ld: library 'System' not found
make: *** [Modules/array.cpython-316.so] Error 1

configure.ac:3687 links iOS extensions against the framework unconditionally:

iOS/*)
    LDSHARED='$(CC) -dynamiclib -F . -framework $(PYTHONFRAMEWORK)'

PYTHONFRAMEWORK is empty without one, so -framework swallows the next argument. libpython3.16.a builds fine; only the shared modules fail.

So a static libpython needs static modules — Kodi passes MODULE_BUILDTYPE=static, which is why it never hit this. The alternatives are -undefined dynamic_lookup (deprecated) or -bundle_loader on the final app executable, which the build can't know.

I'll make configure require MODULE_BUILDTYPE=static for non-framework builds so this fails with a clear message instead, unless you'd rather it went differently.

Follow-up: with MODULE_BUILDTYPE=static and --disable-test-modules, make completes — 46MB libpython3.16.a, 269 objects, stdlib extensions inside it, no .so produced.

So my proposed requirement isn't sufficient alone: _testimportmultiple, xxlimited_35 and xxlimited_3_13 are shared by construction, so MODULE_BUILDTYPE doesn't reach them and they still fail on the empty -framework.

Either require --disable-test-modules too, or mark shared-only modules unavailable when there's no framework (like PY_STDLIB_MOD_SET_NA) so the flags aren't needed. The latter looks better to me — your call, happy to do either.

Ran the stdlib build — you were right, this is broken as it stands.
...
Either require --disable-test-modules too, or mark shared-only modules unavailable when there's no framework (like PY_STDLIB_MOD_SET_NA) so the flags aren't needed. The latter looks better to me — your call, happy to do either.

I feel like I'm having a conversation with an agent rather than a human, except without the ability to actually drive the conversation...

What exactly are you proposing as the options here?

@freakboy3742 yes, there is an AI agent in the loop. I use it to dig through the build system, and I read and approve everything before it gets posted.
But you were right about the shape of the conversation: posting each partial finding instead of coming back with one proposal. That's on me.

3 propositions:

• same as WASM -> iOS with no framework, force MODULE_BUILDTYPE=static and mark the shared-only test modules N/A, so --disable-test-modules isn't needed and the docs state that neither loadable extensions nor binary wheels are supported (this make the changes a bit bigger)
• no implicit behaviour: configure fails unless the user also passes MODULE_BUILDTYPE=static and --disable-test-modules
• I close the PR and Kodi keeps the downstream patch

• no implicit behaviour: configure fails unless the user also passes MODULE_BUILDTYPE=static and --disable-test-modules

My inclination is to go with this - the fully explicit option. A static build is clearly useful, but there will be restrictions on use - I think there is value in requiring the prospective user to explicitly opt into all those options.

These limitations will also need to be documented; a section on static builds (describing both the build process and limitations) to Platforms/Apple/iOS/README.md will be required. It may also be worth mentioning in Doc/using/iOS.rst that the official iOS release artefact is a framework build, but "static builds are also possible with limitations, see the README for details".

Documentation build overview

📚 cpython-previews | 🛠️ Build #34231490 | 📁 Comparing 14b7fc3 against main (fe8ace3)

  🔍 Preview build  

± Modified

• library/os.html
• using/configure.html
• using/ios.html
• using/windows.html
• whatsnew/3.15.html
• whatsnew/changelog.html

Done - pushed the explicit version.

configure now refuses to proceed until you've asked for all of it: MODULE_BUILDTYPE=static, then --disable-test-modules, on top of --disable-framework --disable-shared. One error at a time, each naming the flag that's missing.

Tested here on an arm64-apple-ios build: both errors fire in order, and with all four options the build completes - 46MB libpython3.16.a, stdlib extensions inside the archive, and no .so anywhere in the build tree. I also configured --enable-framework against main and diffed the results: Makefile, pyconfig.h and Setup.stdlib are identical, so framework builds are untouched. Two caveats: I didn't supply libffi/OpenSSL/XZ, so those modules are missing from that particular archive, and the test suite can't run in this configuration by construction.

Docs as you asked: a "Building a static Python" section in Platforms/Apple/iOS/README.md covering the build process and the limitations (no binary wheels, stdlib extensions aren't loadable modules, no test suite, not covered by the Platforms/Apple script or CI), plus a note in Doc/using/ios.rst that the official release artefact is a framework build.