Open manopapad opened 9 months ago
So @CharlelieLrt reports that --global-option
is not working for him. Maybe it has something to do with the pip/setuptools version (mine are pip 23.3.1, setuptools 68.2.2).
And in any case, it looks like --global-option
is deprecated. I tried all the other alternatives suggested on https://github.com/pypa/pip/issues/11859#issuecomment-1778620671, but none of them worked.
At this point I have reached the limits of my (very limited) knowledge around python packaging, so I'll ask @vyasr / @bryevdv / @Jacobfaib to advise: how can I pass the --cmake-executable
command-line option to scikit-build, when going through pip?
give up and ask scikit-build to let us control this through an environment variable
At this point I've resorted to env vars for passing config to build backends in pretty much every situation it's come up. I'm surprised skbuild doesn't already offer the option, is definitely worth an ask.
Unfortunately I don't know of a good way to control this in scikit-build right now either. Based on the code for its CMake inference it should your PATH settings, so perhaps you could force the desired CMake to the front of the PATH? It's just calling shutil.which
under the hood (assuming you didn't install the cmake
pip package).
Just to precise, the desired cmake was already to the front of my PATH, but I think skbuild is picking up in priority cmake3 (which is NOT the desired cmake and is NOT to the front of the PATH).
Oh that is super unfortunate, I missed that it was searching for cmake3. Does it work for you if you alias cmake3 to the desired cmake? (Obviously a workaround, but trying to find a reasonable one for you while we follow up on the scikit-build front)
Yes, I just symlinked cmake3 to the desired cmake and it worked.
OK looked into this a bit further and chatted with scikit-build devs. scikit-build currently takes the first CMake executable that it finds, then errors if the CMake version is too old. That behavior is what you're observing above. That behavior is fixed in the newer scikit-build-core builder (which I've just completed migrating all of RAPIDS to), and I would recommend that legate look into doing that at some point in the future to get the latest and greatest. If using scikit-build-core, while you still wouldn't be able to specify what CMake to use, as long as one of the CMake executables on the path was new enough you would bypass this issue. For fixing the immediate problem, scikit-build devs are going to look into implementing the same fallback behavior that scikit-build-core has in scikit-build so that as long as one of the CMake executables on your path is new enough you won't have any issues.
Separately, for the case of actually passing in a specific executable I've opened https://github.com/scikit-build/scikit-build-core/issues/576. The most likely way that the scikit-build issue will be resolved is by scikit-build-core implementing this feature and then scikit-build classic's internals being refactored to use scikit-build-core. That's always been the long-term goal for unifying the projects.
Just FYI, scikit-build-core now supports specifying CMAKE_EXECUTABLE
as of 0.8.0.
Fixes #837