Skip to content

fix: WIP - IGNORE - Ci fix windows debug due to cmake #2 - #1377

Draft
cedrik-fuoco-adsk wants to merge 2 commits into
AcademySoftwareFoundation:mainfrom
cedrik-fuoco-adsk:ci-fix-windows-debug-due-to-cmake-2
Draft

fix: WIP - IGNORE - Ci fix windows debug due to cmake #2#1377
cedrik-fuoco-adsk wants to merge 2 commits into
AcademySoftwareFoundation:mainfrom
cedrik-fuoco-adsk:ci-fix-windows-debug-due-to-cmake-2

Conversation

@cedrik-fuoco-adsk

Copy link
Copy Markdown
Contributor

Linked issues

Summarize your change.

Describe the reason for the change.

Describe what you have tested and on which operating system.

Add a list of changes, and note any that might need special attention during the review.

If possible, provide screenshots.

The Windows Debug jobs have failed on every nightly since 2026-08-05
with no OpenRV change. Two nightlies of the identical commit 6a3af6e
straddle the boundary: Aug 4 passed, Aug 5 failed.

OpenTimelineIO is built from source against our custom debug Python, and
its setup.py runs find_package(Python ... Interpreter Development.Module)
using the cmake wheel pip installs into the isolated build environment --
not the cmake driving the outer OpenRV build, and not the msys2 one.
That resolution is unpinned, so it floats with PyPI.

cmake 4.4.2 was published to PyPI on 2026-08-04T06:13:31Z, between those
two runs. It contains "FindPython: Add support for pydebug ABI flag on
Windows" (Kitware/CMake 84cb7e262), which reworks how the debug Python
artifacts are located and makes that find_package fail:

  Could NOT find Python (missing: Interpreter Development.Module)
  (found version "3.11.9")

Constrain the build environment via PIP_CONSTRAINT to cmake==4.4.0, the
last version known good on Windows, Linux and macOS. Release builds are
unaffected because they never build OTIO against a debug interpreter.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Windows Debug builds broke when pip started resolving cmake 4.4.2 into
OTIO's isolated build environment. Rather than staying on 4.4.0, adapt
to the new behaviour and move the pin forward.

OTIO's setup.py runs find_package(Python ... Interpreter
Development.Module) against our custom debug Python, whose artifacts
carry the "_d" suffix (python311_d.lib, python_d.exe). cmake 4.4.1
changed two things that together make that search fail:

  * the default Python_FIND_ABI on Windows went from "any ABI except
    gil_disabled" to OFF for every flag, i.e. a release-only search, and
  * FindPython's version/ABI regex went from python([23])([0-9]+)([tdmu]*)
    to ([tdmu_]*), so "python311_d" now reports ABI "_d" rather than no
    ABI at all.

Artifacts that used to read as release-ABI now read as debug-ABI, which
no longer matches the default, producing "Could NOT find Python
(missing: Interpreter Development.Module)".

Pass -DPython_FIND_ABI=ON;ANY;ANY;OFF on Windows Debug to state the ABI
we actually want. The 4-tuple is (pydebug, pymalloc, unicode,
gil_disabled). The semicolons are escaped so the value stays a single
CMake list element and reaches OTIO as one whitespace-delimited
CMAKE_ARGS token; both halves of that were verified locally.

The hint is only correct for 4.4.1+ -- on 4.4.0 the same flag yields
"python311d" instead of "python311_d" -- so the constraint moves to
cmake==4.4.2 in the same commit. It stays an exact pin for
reproducibility rather than tracking whatever PyPI serves that day.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant