nv-legate / legate.core

The Foundation for All Legate Libraries
https://docs.nvidia.com/legate/24.06/
Apache License 2.0
186 stars 61 forks source link

Pass cmake executable to scikit-build #908

Open manopapad opened 9 months ago

manopapad commented 9 months ago

Fixes #837

manopapad commented 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?

bryevdv commented 9 months ago

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.

manopapad commented 9 months ago

Asked at https://github.com/scikit-build/scikit-build/issues/1045

vyasr commented 9 months ago

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).

CharlelieLrt commented 9 months ago

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).

vyasr commented 9 months ago

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)

CharlelieLrt commented 9 months ago

Yes, I just symlinked cmake3 to the desired cmake and it worked.

vyasr commented 9 months ago

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.

vyasr commented 5 months ago

Just FYI, scikit-build-core now supports specifying CMAKE_EXECUTABLE as of 0.8.0.