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

cmake.prefix entry-point can fail when it is pointing to a MultiplexedPath #885

Open
LecrisUT opened this issue Sep 2, 2024 · 2 comments · May be fixed by #880
Open

cmake.prefix entry-point can fail when it is pointing to a MultiplexedPath #885

LecrisUT opened this issue Sep 2, 2024 · 2 comments · May be fixed by #880

Comments

@LecrisUT
Copy link
Collaborator

LecrisUT commented Sep 2, 2024

I am experimenting with building a compiled non-python project within scikit-build-core, and I've encountered an issue if you point the entry-point to a non-pythonic object, i.e.:

[build-system]
requires = ["scikit-build-core"]
build-backend = "scikit_build_core.build"

[project]
name = "CMake-Template"

[project.entry-points."cmake.prefix"]
CMakeTemplatePrefix = "cmake_template"

[tool.scikit-build]
wheel.install-dir = "cmake_template"

The verbose log shows:

    set(CMAKE_PREFIX_PATH [===[MultiplexedPath('/home/lecris/CLionProjects/Template/venv/lib64/python3.12/site-packages/cmake_template');/home/lecris/CLionProjects/Template/venv/lib/python3.12/site-packages]===] CACHE PATH "" FORCE)

Probably should address in #880. But I need to debug more why did it even create MultiplexedPath in this case when I've installed it without editable or such.


Edit: So this is fun. It's a MultiplexedPath with a single item 🤷

@LecrisUT LecrisUT linked a pull request Sep 3, 2024 that will close this issue
10 tasks
@henryiii
Copy link
Collaborator

henryiii commented Sep 3, 2024

We should be able to handle multiplexed paths, that could be a fix before 0.11.

@LecrisUT
Copy link
Collaborator Author

LecrisUT commented Sep 3, 2024

That could be a bit tricky to detangle from 836c51e.

Could be easier if we keep the _handle_search_paths and _sanitize_path parts, but remove the settings_val part from it. Wdyt?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants