Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 9 additions & 2 deletions cmake/dependencies/python3.cmake
Original file line number Diff line number Diff line change
Expand Up @@ -250,6 +250,13 @@ SET(_requirements_output_file

CONFIGURE_FILE(${_requirements_input_file} ${_requirements_output_file} @ONLY)

# Constraints for the build-isolation environments pip creates for packages built from source. Their build requirements are resolved from PyPI on every build
# and are otherwise unpinned, so an upstream release can break a build that has not changed. See the file itself for what is pinned and why. PIP_CONSTRAINT must
# be an absolute path: pip resolves it relative to the working directory of each build-environment subprocess, which is not ours.
SET(_pip_constraint_file
"${PROJECT_SOURCE_DIR}/src/build/pip-build-constraints.txt"
)

# OpenTimelineIO needs to be built from source with CMAKE_ARGS to ensure it uses the correct custom-built Python libraries. This is required for both old and
# new versions of pybind11, especially pybind11 v2.13.6+ which has stricter detection. Note: pybind11's FindPythonLibsNew.cmake uses PYTHON_LIBRARY (all caps),
# PYTHON_INCLUDE_DIR, and PYTHON_EXECUTABLE variables. --no-cache-dir: Don't use pip's wheel cache (prevents using wheels built for wrong Python version)
Expand Down Expand Up @@ -321,7 +328,7 @@ SET(_build_deps_install_command

# Phase 2: Install main requirements (with build-from-source for native extensions)
SET(_requirements_install_command
${CMAKE_COMMAND} -E env ${_otio_debug_env} ${_sdkroot_env}
${CMAKE_COMMAND} -E env ${_otio_debug_env} ${_sdkroot_env} "PIP_CONSTRAINT=${_pip_constraint_file}"
)
# On Windows, the MinGW cmake (from msys2) appears before the Windows cmake in PATH. MinGW cmake defaults to MinGW Makefiles and cannot find the MSVC compiler.
# OTIO's setup.py always calls "cmake" by name from PATH; it does not read CMAKE_GENERATOR. Prepend the directory of our outer build's cmake binary (the Windows
Expand Down Expand Up @@ -493,7 +500,7 @@ ADD_CUSTOM_COMMAND(
OUTPUT ${${_python3_target}-requirements-flag}
COMMAND ${_requirements_install_command}
COMMAND cmake -E touch ${${_python3_target}-requirements-flag}
DEPENDS ${_python3_target} ${${_python3_target}-build-deps-flag} ${_requirements_output_file} ${_requirements_input_file}
DEPENDS ${_python3_target} ${${_python3_target}-build-deps-flag} ${_requirements_output_file} ${_requirements_input_file} ${_pip_constraint_file}
)

# Test Python package imports after requirements are installed. This validates that all pip-installed packages (numpy, opentimelineio, OpenGL, cryptography,
Expand Down
18 changes: 18 additions & 0 deletions src/build/pip-build-constraints.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
# Constraints applied to pip's build-isolation environments when installing the packages in requirements.txt.
#
# Packages built from source (notably OpenTimelineIO) get an isolated build environment whose build requirements are resolved fresh from PyPI on every build.
# Those resolutions float, so an upstream release can break a build that has not changed. Pin the ones that have bitten us here.
#
# cmake: OTIO's setup.py runs find_package(Python ... Interpreter Development.Module) using the cmake wheel installed into its isolated build environment (NOT
# the cmake driving the outer OpenRV build). cmake 4.4.2 added "FindPython: Add support for pydebug ABI flag on Windows" (Kitware/CMake 84cb7e262), which
# changes how the debug Python artifacts are located and makes that find_package fail against our custom debug Python on Windows:
#
# Could NOT find Python (missing: Interpreter Development.Module) (found version "3.11.9")
#
# This broke every Windows Debug CI build from 2026-08-05 onward with no OpenRV change: cmake 4.4.2 was published to PyPI on 2026-08-04T06:13:31Z, between two
# nightly runs of the same commit. 4.4.0 is the last version known good on Windows, Linux and macOS.
#
# TODO: This pin holds the line rather than adapting to the new behaviour. The forward fix is to satisfy 4.4.2+ directly -- likely by passing
# Python_LIBRARY_DEBUG in the CMAKE_ARGS built in cmake/dependencies/python3.cmake, and revisiting the python<ver>_d.lib -> python<ver>.lib copy in that same
# file, which predates cmake's own pydebug support and may now interfere with it. That needs a Windows Debug build to validate before the pin can be lifted.
cmake==4.4.0
Loading