Repository navigation
[BUG]: CMake add_subdirectory() interference from system-installed pybind11 #5937
Description
Required prerequisites
- Make sure you've read the documentation. Your issue may be addressed there.
- Search the issue tracker and Discussions to verify that this hasn't already been reported. +1 or comment there if it has.
- Consider asking first in the Gitter chat room or in a Discussion.
What version (or hash if on master) of pybind11 are you using?
Problem description
When using pybind11 with add_subdirectory, pybind
sets pybind11_system to SYSTEM and then
uses this to pass SYSTEM to target_include_directories().
When this is combined with the parent project adding some global include folder like /usr/include or /opt/homebrew/include as a "normal" include directory, and a version of pybind11 is installed, that folder will take precedence over pybind11's own include folder (cf. CMake target_include_directories doc)
The result are strange compile errors in the best case.
I'd be happy to create a PR that either removes the SYSTEM argument or adds a CMake configuration option to disable it. Currently I am relying on an ugly workaround in our project.
Reproducible example code
Is this a regression? Put the last known working version here if it is.
Not a regression
Activity
JOINKINGER commentedon Sep 3, 2026
I reproduced this with CMake 3.29 and MinGW on Windows. A parent-level include directory for another pybind11 installation is searched before the
add_subdirectorycopy because the latter is classified asSYSTEM.I put together a small local fix and regression test: an opt-out keeps the current default behavior but lets
pybind11_add_module()prefer its source headers when this collision occurs. The test uses a conflicting fake header and passes locally.Are you currently working on a PR? If not, I’d be happy to open one.