use scikit-build-core

[matthiasdiener]

This appears to fix #753.

TODO:

• Nicer config summary
• Nicer way to configure?
• MacOS links against Mac CL framework
• Windows
• pylint (address pylint>=3.2 issues #757)
• update docs

Please squash

[alexfikl]

If we want to switch, why not meson-python instead? The numpy / scipy / matplotlib ecosystem seems to have gone that way and it's probably a good idea to follow..

[matthiasdiener]

If we want to switch, why not meson-python instead? The numpy / scipy / matplotlib ecosystem seems to have gone that way and it's probably a good idea to follow..

TIL, thanks! I think the main reason for using scikit-build-core is that it is what nanobind recommends, and it's used in their examples.

[matthiasdiener]

This seems to work fine and is ready for a first look @inducer. I'm not sure what the best way to replace/reimplement the configure.py functionality is.

[alexfikl]

This seems to work fine and is ready for a first look @inducer. I'm not sure what the best way to replace/reimplement the configure.py functionality is.

What functionality exactly? Generally the configuration can be done in CMakeLists.txt and you can pass it arguments using

pip install . --config-settings='cmake.args=-DSOME_DEFINE=ON;-DOTHER=OFF'

[alexfikl]

These should also be defined in CMakeLists.txt as option(PYOPENCL_TRACE "Enable tracing functionality" OFF)? At least that's idiomatic from what I recall..

[matthiasdiener]

Done in 34a47d9

[alexfikl]

Could this logic be in CMakeLists.txt? Something like if($ENV{CONDA_PREFIX}) set(CL_INC_DIR "${CONDA_PREFIX}/include")?

[matthiasdiener]

I'm not sure, it feels a bit strange for the CMakeLists.txt file to know about conda.

[inducer]

I agree, but maybe the logic could be made conditional on there being an OpenCL library in the conda env? If there is, I think there is an overwhelming likelihood it should be used. And PyOpenCL's documentation talks about conda as a means to install, so it's not like the two projects are totally unrelated.

[alexfikl]

For context, on my system (cmake 3.29.3) there are a few cmake modules that look at CONDA_PREFIX in particular: GNUInstallDirs.cmake, UnixPaths.cmake and FindPython/Support.cmake.

So I don't think there's anything strange about teaching the build a bit more about the platform, which in this case is conda.

[alexfikl]

Also, looking at FindOpenCL.cmake, it seems like we can set OCL_ROOT=$CONDA_PREFIX to let it find the right folders itself.

[matthiasdiener]

TIL, thanks. conda support was added in 9b3c600

[matthiasdiener]

What functionality exactly? Generally the configuration can be done in CMakeLists.txt and you can pass it arguments using

More specifically, I meant an easy-ish way for the user to configure the build, similar to the configure.py / siteconf.py system in the current version.

pip install . --config-settings='cmake.args=-DSOME_DEFINE=ON;-DOTHER=OFF'

Yeah, that is an option for replacing configure.py. Additionally, I was thinking of providing a siteconf.cmake file similar to siteconf.py.

[inducer]

I think ditching the configure.py mechanism is the right approach at this point. As long as we document the cmake.args way (also maybe add an entry to the changelog), I think that's OK.

[matthiasdiener]

Here are the OpenCL config options that we have been discussing (all except nr. 4 should work with the current state of this PR):

1. Get path from CONDA_PREFIX if set
2. siteconf.cmake
3. Environment variables
4. Having some kind of configure.py-like frontend (that calls pip install with the right options?)
5. pip install . --config-settings='cmake.args=-D....'
6. Fallback: let's just have cmake try to find OpenCL

If I understood correctly, option 4 isn't really desired. Are there any other options we should add/remove? (e.g., perhaps sieconf.cmake isn't necessary?)

Besides the question above, this is ready for a second look (in particular, regarding the next steps).