scikit-build-core
scikit-build-core copied to clipboard
scikit-build
Support SKBUILD_CONFIGURE_OPTIONS and SKBUILD_BUILD_OPTIONS
scikit-build classic supported these two environment variables for configuring the build. classic also supported the CMAKE_ARGS environment variable, and that one has been translated to scikit-build-core. CMAKE_ARGS is more important for baseline support because it is used by conda-build, so having it working is critical for interop with that ecosystem, but more generally I prefer SKBUILD_CONFIGURE_OPTIONS as a better scoped (and more clearly named) variable. I don't believe there is any analog for SKBUILD_BUILD_OPTIONS in scikit-build-core.
If there is interest in having these supported I'm happy to make a PR to add that support.
It's now called SKBUILD_CMAKE_ARGS (and is just the environment variable version of cmake.args option/setting).
I don't think there's a reason to support SKBUILD_BUILD_OPTIONS now that we have CMAKE_BUILD_PARALLEL_LEVEL and a verbose option/var/setting. Was there something else that could go in here?
Looking at https://cmake.org/cmake/help/latest/manual/cmake.1.html#build-a-project, I don't think there's much else that makes sense here? We'd probably want custom support for presets, plus it's 3.19+, I think. We can have custom targets support eventually (as long as that still works with install, I think we should support install components instead of supporting replacing "install" with a custom target).
We'd probably want custom support for presets, plus it's 3.19+, I think
Yes, presets were introduced in 3.19, but it is hard to design around before preset version 4 (3.23) and 6 (3.25). But the funny thing about presets is that you can implement them even though the project itself does not support those cmake versions. Only the caller of the presets (usually the CI or in this case sk-core) has to be using those cmake versions. Unfortunately these cannot be back-ported like the python utilities, but since it mostly affects CI's and individual's workflows, it can be implemented as a preference if the cmake version supports it, otherwise default to the default workflow.
Aha I totally missed that every one of the config variable is also accessible as an environment variable. It is documented, so largely an oversight on my part.
I don't see anything critical in that list at the moment, but let me ask some CMake experts to make sure I'm not missing anything. The one thing that perhaps comes to mind is controlling parallelism in cases where either 1) you're using Make or another generator that doesn't parallelize by default or 2) you are using Ninja or a by-default parallel generator but you need to limit the parallelism to avoid overtaxing your system's resources.
A few crucial ones are preset, trace and debug-find. The latter two are for debugging and internal use for scikit-build-core, so it should be custom handled. And preset is a whole new implementation workflow. Here's the list of cmake options for the record.
A concern is that since you support CMAKE_GENERATOR you support the Ninja Multi-Config generator, therefore you need to support --config so that you get the correct build type
Also MSVC, which is the default on Windows! That's supported (via cmake.build-type), though I don't support setting more than one at a time. I've seen that done with some very interesting applications for debugging in py-build-cmake, so I might look into supporting setting multiple eventually.
(Also I forgot about --config in editable mode until recently, but that's now fixed.)
preset, trace and debug-find
Those are used for configuration, though, not --build, right (except for --preset)? We support arbitrary configuration options via cmake.args / [SKBUILD_]CMAKE_ARGS. The list for --build is at https://cmake.org/cmake/help/latest/manual/cmake.1.html#build-a-project.
Also MSVC, which is the default on Windows! That's supported (via cmake.build-type), though I don't support setting more than one at a time. I've seen that done with some very interesting applications for debugging in py-build-cmake, so I might look into supporting setting multiple eventually.
(Also I forgot about
--configin editable mode until recently, but that's now fixed.)
CMAKE_BUILD_TYPE has no impact on multi-config generators. You need to specify the config type at build and test time to control what is used.
I don't know how/if skbuild-core triggers ctest but that also has extra complexity around multi-config generators, mainly with it using -C/--build-config instead of --config and the fact that while MSVC generators will run without an explicit config, that isn't the case for ninja multi-config
In theory you could use CMAKE_CONFIGURATION_TYPES to set the multi-config supported config types to a single value. But that would remove the ability of intreset from py-build-cmake.
CMAKE_BUILD_TYPE has no impact on multi-config generators.
I meant [tool.scikit-build] cmake.build-type is used to set this, and defaults to "Release" currently, though in the future it might match CPython ("Release" if CPython is a release build, and "Debug" if CPython is a debug build). It does pass --config <...> when building if a multi-config generator is detected. (Our detection of them isn't ideal just yet).
Currently we do not have a way to trigger CTest, and I'm not sure if that would make sense. If you want to run C/C++/whatever tests, you could just run CMake directly. If you want to run Python tests, you'd build the package then run pytest or whatever you need from Python.
the fact that while MSVC generators will run without an explicit config, that isn't the case for ninja multi-config
I suspect this might be why I had a bug for a while with --config missing for editable installs, maybe it was working on MSVC and someone only noticed when using ninja multi-config.
+1 on supporting SKBUILD_BUILD_OPTIONS (analogous to cmake --build <dir> -- [build tool options...]). Both Make and ninja support -l, which can be used in conjunction with -j to limit parallelism with respect to overall CPU load (and I use CPU load as a crude limiting estimate when compiling multiple device architectures with nvcc).
I assume others use make or ninja specific flags as well, e.g. -B|--always-make, -d|--debug --jobserver-auth, etc., so I think it's worthwhile for SKBC to support arbitrary build tool flags a user may want to pass.
