Skip to content

Bridge Python3_INCLUDE_DIRS when only the unversioned Python module was found - #13

Open
take-cheeze wants to merge 1 commit into
mainfrom
claude/bridge-python3-include-dirs
Open

take-cheeze wants to merge 1 commit into
mainfrom
claude/bridge-python3-include-dirs

Conversation

@take-cheeze

Copy link
Copy Markdown
Member

Summary

find_package(Python 3 ...) and find_package(Python3 ...) are separate CMake modules with separate hint/output variable namespaces. nanobind's own CMake config reads the versioned, plural Python3_INCLUDE_DIRS variable specifically — it's never populated by the unversioned find_package(Python ...) call this file uses for ONNX_BUILD_PYTHON.

On a normal host build this goes unnoticed, because something else in the dependency graph (onnx's own CMakeLists.txt) has usually already called find_package(Python3) and populated it first. Cross-compiling can reach this find_package(Python) call with nothing else having populated the Python3_* variables yet — nanobind_add_module then fails with Python.h file not found immediately afterward, despite Development.Module having just been found successfully one line above.

Found while cross-compiling onnxsim (github.com/onnxsim/onnxsim) for Pyodide/wasm32-emscripten — see that repo's docs/wasm_pyodide.md for the full context. Its own build script currently has to work around this by passing both Python3_* and unversioned Python_* CMake hints from the calling side; this fix bridges the gap at the source instead.

The fix

Minimal and guarded: after the existing find_package(Python 3 ...) call, set Python3_INCLUDE_DIRS from Python_INCLUDE_DIRS only if the former isn't already defined. No behavior change to the find_package call itself, and it's a no-op on any build where Python3_INCLUDE_DIRS is already populated (i.e. every normal host build) — it only kicks in for the specific cross-compile ordering gap described above.

Test plan

  • Confirmed this is the exact root cause via direct investigation while cross-compiling onnxsim for wasm32-emscripten (reproduced the Python.h file not found failure, confirmed it disappears once Python3_INCLUDE_DIRS is populated)
  • Not separately re-verified in this PR against a fresh wasm32 rebuild (the fix mirrors a workaround already validated end-to-end in the downstream onnxsim investigation) — happy to re-verify if requested

Generated by Claude Code

…as found

find_package(Python 3 ...) and find_package(Python3 ...) are separate
CMake modules with separate hint/output variable namespaces. nanobind's
own CMake config reads the versioned, plural Python3_INCLUDE_DIRS
variable specifically -- it is never populated by the unversioned
find_package(Python ...) call this file uses for ONNX_BUILD_PYTHON.

On a normal host build this goes unnoticed because something else in the
dependency graph (onnx's own CMakeLists.txt) has usually already called
find_package(Python3) and populated it first. Cross-compiling (found
while cross-compiling for wasm32-emscripten via onnxsim, see
github.com/onnxsim/onnxsim's docs/wasm_pyodide.md) can reach this
find_package(Python) call with nothing else having populated the
Python3_* variables yet, and nanobind then fails with "Python.h file not
found" immediately afterward, despite Development.Module having just
been found successfully.

Bridge it explicitly instead of relying on incidental ordering elsewhere
in the build. Guarded so it's a no-op whenever Python3_INCLUDE_DIRS is
already set.
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.

2 participants