Documentation build overview

📚 cpython-previews | 🛠️ Build #35012603 | 📁 Comparing 082c16e against main (7aec160)

  🔍 Preview build  

+ Added

• builtins/constants.html
• builtins/exceptions.html
• builtins/functions.html
• builtins/index.html
• builtins/stdtypes.html
• builtins/threadsafety.html
• builtins/time-complexity.html
• library/time-complexity.html
• library/tkinter.dialogs.html

± Modified

• glossary.html
• index.html
• license.html
• py-modindex.html
• c-api/arg.html
• c-api/bool.html
• c-api/buffer.html
• c-api/bytearray.html
• c-api/bytes.html
• c-api/capsule.html
• and 386 more...

Marking as draft as Xcode/iOS 27 testing hasn't started yet. Feel free to undo that when the time comes.

!buildbot iOS

🤖 New build scheduled with the buildbot fleet by @freakboy3742 for commit 0378698 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F155222%2Fmerge

The command will test the builders whose names match following regular expression: iOS

The builders matched are:

• iOS ARM64 Simulator PR

Update: Xcode 27 is now generally available; this PR passes on Xcode 27 (tested locally) and on Xcode 16 (the buildbot configuration), but breaks on Xcode 26 (CI configuration). I'm investigating why...

So, it appears that macOS 26 SDK doesn't export the dup3/pipe2 symbols, whereas the iOS 26 SDKs do - but they break if you try to compile against them. I've reworked the configure script so that it will detect correctly based on an actual link, rather than the base autoconf functionality check.

It's worth noting a couple of things here:

1. The documented requirement doesn't seem quite right - the calls won't be available based purely on "macOS/iOS 27+" - the feature will only be available if the user has that OS version, and we compile using a macOS/iOS 27+ SDK. That won't be true for iOS until we switch to a (not yet available) macos-27 runner, or we use the (currently in preview) xcode-27 runner. I'm not 100% of the compilation environment that @ned-deily is using for macOS builds, but if it's the macos-26 Github runner, it won't expose the SDK.
2. dup3 won't have much use on iOS, as it doesn't support fork and spawn.

!buildbot iOS

🤖 New build scheduled with the buildbot fleet by @freakboy3742 for commit 5e703b2 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F155222%2Fmerge

The command will test the builders whose names match following regular expression: iOS

The builders matched are:

• iOS ARM64 Simulator PR

!buildbot iOS

🤖 New build scheduled with the buildbot fleet by @ned-deily for commit 082c16e 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F155222%2Fmerge

The command will test the builders whose names match following regular expression: iOS

The builders matched are:

• iOS ARM64 Simulator PR

So, it appears that macOS 26 SDK doesn't export the dup3/pipe2 symbols, whereas the iOS 26 SDKs do - but they break if you try to compile against them. I've reworked the configure script so that it will detect correctly based on an actual link, rather than the base autoconf functionality check.

It is not a huge issue but I think always using the actual link vs the autoconf check is overkill and takes away some existing functionality for macOS builds and also touches builds on other platforms. In particular, by no longer using the autoconf check, it would no longer be possible to build for macOS 27 (or iOS 27) on macOS 26 with Xcode 27, something which Apple does support ("Xcode 27 requires a Mac running macOS Tahoe 26.6 or later on Apple silicon.").

Rather than abandoning the autoconf tests, I believe the build problems can be avoided by only skipping the checks for dup3 and pipe2 when building for iOS with an IOS SDK less than 27. The revised PR now does that.

I've tested building with both Xcode 26.6 and 27.0 on both macOS 26.7.1 and 27.0.1 for macOS, iOS, and both iOS simulators and running make testios (with no errors) for the arm64 IOS simulator and verified that configure produced the expected pyconfig.h values in all cases.

Thanks for the review & merge!