Conversation
|
|
||
| else() | ||
| find_package(Eigen3 3.2.7 QUIET CONFIG) | ||
| find_package(Eigen3 3.2.7...5 QUIET CONFIG) |
There was a problem hiding this comment.
With a lot of help from Cursor GPT-5.4 Extra High Fast:
One small suggestion: I think this would be a bit clearer and more robust as a two-step CONFIG probe instead of 3.2.7...5.
I checked this locally, and 3.2.7...5 is not a wildcard for “any 5.x” in standard CMake version semantics. It is a bounded range whose upper endpoint is effectively 5.0.0. The reason this still passed with Eigen 5.0.1 in CI seems to be that the particular package version file accepted it, but that is package-specific behavior rather than something I would want to rely on.
Something like this seems safer and more explicit:
diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt
@@
- find_package(Eigen3 3.2.7...5 QUIET CONFIG)
- set(EIGEN3_FOUND ${Eigen3_FOUND})
- set(EIGEN3_VERSION ${Eigen3_VERSION})
+ find_package(Eigen3 3.2.7 QUIET CONFIG)
+ if(NOT Eigen3_FOUND)
+ find_package(Eigen3 5 QUIET CONFIG)
+ endif()
+ set(EIGEN3_FOUND ${Eigen3_FOUND})
+ set(EIGEN3_VERSION ${Eigen3_VERSION})
if(NOT EIGEN3_FOUND)
# Couldn't load via target, so fall back to allowing module mode finding, which will pick up
# tools/FindEigen3.cmake
# XXX: MODULE mode does not work with Eigen 5
find_package(Eigen3 3.2.7 QUIET)Also, please add something like the following to the PR description:
This intentionally fixes the
CONFIG-mode path and normalizes the legacyEIGEN3_*variables after theCONFIGprobe. It does not touch the oldtools/FindEigen3.cmakelogic, which is more invasive and easier to get wrong. In other words, this is a targeted compatibility fix for environments that provide anEigen3Config.cmake, while leaving the legacy MODULE-mode finder as a fallback for older setups.
I think that extra explanation would help reviewers understand why this “band-aid” approach is actually a good first step here.
|
Dumping this here JIC it's useful later: |
|
Also dumping this here JIC it's useful later: Cursor GPT-5.4 Extra High Fast 1. What determines which Eigen version a job uses now, and will that float?Jobs fall into two buckets. Jobs that pass - name: Configure
run: >
cmake -S. -Bbuild -Werror=dev
-DPYBIND11_WERROR=ON
-DPYBIND11_PYTEST_ARGS=-v
-DDOWNLOAD_CATCH=ON
-DDOWNLOAD_EIGEN=ON
${{ inputs.cmake-args }}set(PYBIND11_EIGEN_VERSION_AND_HASH
"3.4.0;929bc0e191d0927b1735b9a1ddc0e8b77e3a25ec"
CACHE STRING "Eigen version to use for tests, format: VERSION;HASH")Jobs that do not pass
- uses: actions/checkout@v6
- name: Add Python 3
run: apt-get update; apt-get install -y python3-dev python3-numpy python3-pytest python3-pip libeigen3-dev
- name: Update pip
run: python3 -m pip install --upgrade pip
- name: Update CMake
uses: jwlawson/actions-setup-cmake@v2.2
- name: Configure
shell: bash
run: >
cmake -S . -B build
-DPYBIND11_WERROR=ON
-DDOWNLOAD_CATCH=ON
-DCMAKE_CXX_STANDARD=${{ matrix.std }}
-DCMAKE_CXX_FLAGS="${{ matrix.cxx_flags }}"
-DPYTHON_EXECUTABLE=$(python3 -c "import sys; print(sys.executable)") - sys: mingw64
env: x86_64
extra_install: |
mingw-w64-x86_64-python-numpy
mingw-w64-x86_64-python-scipy
mingw-w64-x86_64-eigen3So the practical answer is:
|
Description
fix #6034
3.2.7matches 3.2.7 to <3.3Eigen3_FOUNDbut notEIGEN3_FOUNDSuggested changelog entry: