Support cmake presets

[henryiii]

trafficstars

Example: https://github.com/1yefuwang1/vectorlite/blob/main/setup.py

We should add a preset option, maybe cmake.preset, and then we can try to read the values from here that affect us, like binaryDir.

[LecrisUT]

It just occurred to me that you can just overwrite binaryDir, e.g.:

$ cmake --preset default -B /path/to/scikit-build-build

Heck, you can even do this:

$ cmake -S .. --preset=default -B other-build

It would not work for build/test/workflow presets though, but should those even be supported right now?

What about for first pass to add cmake.preset and just have the -D, -C take care of the overwrite initially?

[henryiii]

I think overriding the binaryDir probably makes sense; in which case, is there anything that we could provide that would be better than doing cmake.args = ["--preset=default"] now? Build presents do require a build.preset setting since we don't provide arbitrary args to build, but IMO that's fine.

I think we should make a new configure / config section instead of continuing to put everything in cmake.

[LecrisUT]

I think we should make a new configure /config section instead of continuing to put everything in cmake.

Agree, that would make more sense. Maybe even install, but that might clash with wheel-* stuff which would be better to have on top level so that it follows hatchling configuration?

I think overriding the binaryDir probably makes sense; in which case, is there anything that we could provide that would be better than doing cmake.args = ["--preset=default"] now?

Effectively it should be cmake.args = ["--preset=default"] , but having a dedicated option would make it more intuitive and easy to expand later on. Also good to fix the config API for the eventual 1.0.

Build presents do require a build.preset setting since we don't provide arbitrary args to build, but IMO that's fine.

I mean we can't override the binaryDir like we do for the configurePreset (not sure why it doesn't allow the override TBH, maybe it needs a PR to fix that).

[starball5]

Duplicate of #515?

[LecrisUT]

Yes, there are actually 3+ such issues :). But occasionally inspiration strikes

[henryiii]

Another thing that would be nice if we supported presets explicitly: https://github.com/orgs/scikit-build/discussions/1115#discussioncomment-10488748

[LecrisUT]

You mean reading the generator from the preset? Well that's an equally difficult issue to the binary-dir if we don't parse the Presets.json. Maybe we could just add a parser, but it's annoying that many variables like include supports macro expansions

[starball5]

Why is parsing needed? Can you not just generate the buildsystem and then use the file API or something?

[henryiii]

We need to know what build system is expected before we declare cmake is required because we need to declare ninja at the same time if it's required. We also need to know if we need to pass build-type Release/Debug, etc. flags when generating the build system. So basically we have to be able to parse quite a bit of this to support it (in a more integrated manner, that is - you can do it today by just manually overriding with the correct generator and build-type).

[starball5]

I just found https://github.com/scikit-build/scikit-build-core/issues/515#issuecomment-2314986831... would be nice if this wasn't scattered across multiple issue tickets.

[thebest132]

@henryiii You should really have this. Also, environment variables don't seem to work in cmake.args

[henryiii]

Have what? Work for presets is started in #994.

Also, environment variables don't seem to work in cmake.args

Because they aren't environment variables, they are arguments to CMake? You can use environment variables in cmake.define, there's an option to take an environment variable and convert it into a define. You can also use environment variables with overrides, which allows pretty much anything.