Support for CMake Presets?

[se7kn8]

Is there any support for CMakePresets.json?

[LecrisUT]

Not yet, but maybe it's worth discussing this:

• major blocker: extracting build directory from the preset
  Unfortunately there doesn't seem to be a cmake native way of doing so and manually resolving it would be tricky since the presets are still a moving target and the build directory can be hidden in inheritance and environment variable
• what level of support to have?
  Workflow supports would be tricky because they don't allow to override settings, but probably only configure and build preset would be fine?
• in which direction should the preset support go? Should the user provide the preset or sb-core?
  On one hand sb-core needs to inject cache variables, sometimes dynamically. On the other hand you might want to reuse the configuration generated by sb-core

What are your thoughts and priorities on this? How do you envision the preset support to be like?

[se7kn8]

My use case would be the following:
For a project we have some OS-specifc presets in a CMakeToolchain file (for example one for GCC and one for MSVC). Since our project is build with cibuildwheel for every platform, it would be nice to be able to set the preset that scikit-build-core uses by environments variables. The build folder could still be manually set, so that wouldn't be problem.

[t1-nva]

Not yet, but maybe it's worth discussing this:

• major blocker: extracting build directory from the preset
  Unfortunately there doesn't seem to be a cmake native way of doing so and manually resolving it would be tricky since the presets are still a moving target and the build directory can be hidden in inheritance and environment variable
• what level of support to have?
  Workflow supports would be tricky because they don't allow to override settings, but probably only configure and build preset would be fine?
• in which direction should the preset support go? Should the user provide the preset or sb-core?
  On one hand sb-core needs to inject cache variables, sometimes dynamically. On the other hand you might want to reuse the configuration generated by sb-core

What are your thoughts and priorities on this? How do you envision the preset support to be like?

Wouldn't it be possible to use the CMake file API to extract the information about the generated build system, including binary directory etc.?

https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html#object-kinds

[LecrisUT]

Wouldn't it be possible to use the CMake file API to extract the information about the generated build system, including binary directory etc.?

Unfortunately not, because the file-api files are under the build directory ¹ 😮‍💨.

We did brainstorm it a bit more in #790. Basically if we limit the support to configurePreset, we can just override the build directory with -B. You can even technically use it right now if you pass it cmake.args = ["--preset=default"].

Footnotes

1. https://cmake.org/cmake/help/latest/manual/cmake-file-api.7.html#introduction ↩

[starball5]

Unfortunately not, because the file-api files are under the build directory

@LecrisUT if the issue is getting the build directory after running configuration, why not just use the fact that when running configuration via commandline, CMake prints a message about where the build directory is? ("-- Build files have been written to:")

https://github.com/Kitware/CMake/blob/7537fec12573387b716c0f42c6ff9aa95965fcb6/Source/cmake.cxx#L2894

https://github.com/Kitware/CMake/blob/master/Source/cmakemain.cxx#L190

[LecrisUT]

Isn't that message written at the end of it. How to deal if the build threw a FATAL_ERROR, e.g. it requested a generator that it did not support.

[henryiii]

We don't intercept or parse the output. That is very fragile and users can output anything they want. Parsing the presets would be easier.

[starball5]

@henryiii It's not a user-defined output. It's a CMake output that CMake prints at the end of running configuration via commandline. I'm not sure that you understood the context of my previous comment.

@LecrisUT If configuration fails because an unsupported generator was requested, then why should scikit-build try to do something to "deal with it"? Just fail the operation.

[LecrisUT]

@henryiii It's not a user-defined output. It's a CMake output that CMake prints at the end of running configuration via commandline. I'm not sure that you understood the context of my previous comment.

The issue is a message printed by CMake is indistinguishable by a message printed by the user.

@LecrisUT If configuration fails because an unsupported generator was requested, then why should scikit-build try to do something to "deal with it"? Just fail the operation.

Because skbuild supports adding ninja dynamically to the build-system.requires.

[starball5]

The issue is a message printed by CMake is indistinguishable by a message printed by the user.

It's printed at the end of configuration. It's generally the last thing that gets printed.

Because skbuild supports adding ninja dynamically to the build-system.requires.

Why not compromise? Just limit support to configure presets that don't depend on inheritance or default generator discovery procedure.