Stable ABI filename new form in 3.15+ #1525

In 3.15+, foo.abi3-x86-64-linux-gnu.so will become a valid name (alongside the existing foo.abi3.so), see python/cpython#152461. CMake issue reported at cmake/cmake!27997.

🤖 AI text below 🤖

CMake — silent behavior flip, needs a deliberate decision. Python3_SOSABI is computed by taking the first EXTENSION_SUFFIXES entry matching ^\.abi (Modules/FindPython/Support.cmake:766-781). Since your PR orders the tagged suffixes first, configuring against 3.15+ flips SOSABI from abi3 to abi3-<triplet>, and every Python_add_library(... USE_SABI x WITH_SOABI) target starts getting platform-tagged names automatically. Nothing errors — but a wheel built on 3.15 and tagged cp39-abi3 becomes unimportable on 3.9–3.14 purely because of the filename. CMake probably wants to prefer the bare .abi3.so/.abi3t.so entry by default (or gate the tagged form on the requested SABI version ≥ 3.15). Bonus latent bug found: on free-threaded 3.13/3.14 (no .abi* suffix exists yet), the probe's failure discards the abi3t static default instead of falling back to it, leaving SOSABI empty and modules named bare .so. This ordering-driven auto-flip is also worth weighing on the CPython side — it's the direct consequence of putting tagged suffixes first.

scikit-build-core — small fixes now, opt-in feature later. Its own get_soabi hardcodes bare abi3/abi3t (builder/sysconfig.py:239-245), which stays valid and is the right default. But because FindPython (upstream and the vendored backport at resources/find_python/FindPython/Support.cmake:587) will flip as described above, WITH_SOABI USE_SABI projects get tagged names on 3.15+ regardless, and two tests hardcoding abi3_example.abi3.so (tests/test_pyproject_abi3.py:63, tests/test_setuptools_abi3.py:75) will fail. To deliberately produce tagged names, the single change point is get_soabi using the new SOABI_PLATFORM sysconfig var — but only when the SABI target is ≥ 3.15, and with care in cross-compilation (the triplet must come from target config, not the running interpreter; the SETUPTOOLS_EXT_SUFFIX escape hatch currently bypasses SABI builds entirely). The audit also turned up a pre-existing bug worth fixing regardless: the abi3t template sets Python_SOABI (resources/templates/abi3t/CMakeLists.txt:12) but USE_SABI reads Python_SOSABI in FindPython ≥ 3.26, so the override is a no-op.