For thewasi.py changes.

Ithink the macOS changes makes sense, but I'll defer to@ned-deily's experience with the historical context on the workaround that has been removed.

A couple of minor issues flagged with the Emscripten pieces.

My approach to reviewing this PR was to do a few before and after builds on macOS. My primary focus was differences in the generatedMakefiles and the contents of the generatedpybuilddir.txt file.

There appear to be three differences in the Makefile:

1. The addition of the newPYBUILDDIR variable:

> PYBUILDDIR = "build/lib.darwin-darwin-3.14-t"

2. The paths for the shared module .so's in theSHAREDMODS variable now point to thebuild/lib.<platform> directory rather than the previous symlinked path in theModules directory:

< SHAREDMODS = "Modules/array.cpython-314t-darwin.so Modules/_asyncio.cpython-314t-darwin.so [...]> SHAREDMODS = "build/lib.darwin-darwin-3.14-t/array.cpython-314t-darwin.so build/lib.darwin-darwin-3.14-t/_asyncio.cpython-314t-darwin.so [...]

3. The addition of the newSYSCONFIGDATA* variables:

> SYSCONFIGDATA_NAME = "_sysconfigdata_t_darwin_darwin"> SYSCONFIGVARS_DEPS = "\"> SYSCONFIGVARS_JSON_NAME = "_sysconfigvars_t_darwin_darwin.json"> SYSCONFIG_SRC = "\"

In addition, the contents of the generatedpybuilddir.txt file (and, thus, the name of the directory where the.so files are built) has changed for macOS. For example, in this case building with./configure --disable-gil --with-pydebug with a deployment target of macOS 15.4:

< build/lib.macosx-15.4-arm64-3.14> build/lib.darwin-darwin-3.14-td

A lot of the differences here (and the "technical debt") can be attributed to the support in the Makefile prior to 3.11 for two different mechanisms for building standard library extension modules: the (older) explicit method using theModules/Setup* files and the (slightly newer) Distutils-basedsetup.py method. Both co-existed and explain why there were the .so symlinks, i.e. because Distutils built.so's in thebuild/lib.<platform> directory while theModules/Setup* files built them in theModules directory and the installed build was based on what was inModules. After the major changes in 3.11 and subsequent releases that removedsetup.py and the build dependency on Distutils, some artifacts remained, including (AFAIK) continued support forModules/Setup*; this area has never been particularly well-documented.

I (and, I expect, most other core devs) have very little personal experience with usingModules/Setup.local to tailor a build (or to what extent, if any, it all still works the same in 3.14 as it did prior to 3.11). So before making any changes that might affect builds that useModules/Setup.local, I think these changes need to be reviewed by people who actually use it.@Yhg1s might be a good starting point for this. And also@erlend-aasland as having been involved in making the changes for 3.11 and beyond.

AFAICT, the difference in the build/lib.* names for macOS builds should not be a big deal for most builders since the use of the path was essentially isolated to the Makefile outside ofpybuilddir.txt and it didn't have any influence on an installed Python. I would guess that few people running Python from a build directory (rather than from an installed location) would be affected by the change in directory name, particularly if they are usingpybuilddir.txt. I'm not sure why Distutils included the deployment target (i.e. the15.4) and/or the Mac architecture (arm64) in the build directory name but it might have allowed using one top-level build directory for multiple invocations of./configure. I would be surprised if anyone were actually doing that (if it ever worked); using separate top-level build directories for each build configuration would be a simple fix and safer approach if so. (And, of course, it was the use of these variables in the directory name that lead to the "chicken-and-egg" circular dependency in the first place so that's a plus point.)

So, in summary, I don't see any significant macOS-specific problems with the PR as it stands. But the PR should be reviewed by someone with hands-on experience with usingModules/Setup.local in a post-3.11 environment.