Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass cmake executable to scikit-build #908

Open
wants to merge 1 commit into
base: branch-24.03
Choose a base branch
from

Conversation

manopapad
Copy link
Contributor

Fixes #837

@manopapad manopapad added the category:bug-fix PR is a bug fix and will be classified as such in release notes label Dec 6, 2023
Copy link

@Jacobfaib Jacobfaib left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢 it

join = os.path.join
exists = os.path.exists
dirname = os.path.dirname
realpath = os.path.realpath
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's wrong with

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

at the top? Then several places can be shortened

@manopapad
Copy link
Contributor Author

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
Copy link
Contributor

bryevdv commented Dec 8, 2023

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
Copy link
Contributor Author

Asked at scikit-build/scikit-build#1045

@vyasr
Copy link

vyasr commented Dec 8, 2023

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
Copy link

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
Copy link

vyasr commented Dec 12, 2023

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
Copy link

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

@vyasr
Copy link

vyasr commented Dec 15, 2023

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.

@marcinz marcinz changed the base branch from branch-24.01 to branch-24.03 February 22, 2024 00:53
@vyasr
Copy link

vyasr commented Mar 20, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:bug-fix PR is a bug fix and will be classified as such in release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

install.py ignores --with-cmake for scikit-build
5 participants