Pass cmake executable to scikit-build

[manopapad]

Fixes #837

[Jacobfaib]

🚢 it

[bryevdv]

What's wrong with

from  os.path import dirname, exists, join, realpath

at the top? Then several places can be shortened

[manopapad]

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 pypa/pip#11859 (comment), 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?

• figure out the right incantation involving --global-option/--build-option/--config-setting
• put this setting in a setup.py/setup.cfg/whatever file (but note that the point here is that we let the user override this setting dynamically)
• give up and ask scikit-build to let us control this through an environment variable
• give up on letting the user supply a specific cmake executable
• something else?

[bryevdv]

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]

Asked at scikit-build/scikit-build#1045

[vyasr]

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]

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]

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]

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

[vyasr]

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 scikit-build/scikit-build-core#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]

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