workflow usage

Usage
1

I am wondering what the thinking is behind options associated with --preset .
It appears that -S is allowed for configuration presets but not build and workflow presets.
Why is -S not allowed?

Secondary Topic:
Why is specifying the source directory not supported in a preset?

The following is why I think this is the case.

> cmake --workflow --list-presets -S .
Unknown argument -S
Usage: cmake --workflow [options]
Options:
  --preset <preset> = Workflow preset to execute.
  --list-presets    = List available workflow presets.
  --fresh           = Configure a fresh build tree, removing any existing cache file.
2

Because the CMakePresets.json file has to live in the source directory, so that’s implicitly the source directory.

3

Where the CMakePresets.json file lives is a source directory.
But that can be said about (many) CMakeLists.txt files as well but their source directory can be indicated with the -S <path> option if the preset is of type configure.

4

Preset files are different. CMake only looks in the current working directory, and they’re supposed to be only at the root of the project.

5

But if all I have are configure presets then the -S option does its job.
Why do the behavior of --build and --workflow differ.
It sounds like you are saying “it is just different”.

6

It is different. They do different things. They have different parameters and conventions.

7

Let me start over.
I understand that --preset can be of different types and that those types have different semantics.
What I want to understand is which of these differences motivated the implementation where -S is present for --preset and prohibited for --build --preset and --workflow --preset.

Here is my thought which might cause other choices:

It is my understanding that workflow targets (at least in part) continuous-integration.
It is generally considered bad form to cd in the CI tool and that the working directory be specified as an option to the build tool. (Yes, I am aware of the hacks to accommodate this.)

Overloading the -S option to effectively set the working directory might be a problem but if I am doing an out-of-source build wouldn’t I expect the CMakePresets.json to not be in my project root?

I also noticed the cmake --help only shows the configuration preset.

8

The CMakePresets.json file is expected to always be in the top level source directory. That is true even if doing an out-of-source build. Currently, there’s no alternative but to cd to the top source directory and run your workflow preset from there.

I understand your use case, and I also have encountered similar situations. I too think workflow presets need some way to allow per-step command line options somehow, at least for passing through arguments for the configure step. At the moment, only one or two are passed through as special cases, but it is clear from personal experience that we want to pass through more, ideally all configure options. It isn’t clear how we might do that though.

1 Like
9

Can I ask a related question? It looks like -D options are not allowed in workflow presets either. Is that intended or am I missing something how to pass the option?

For example, in a project with an option like this:

# CMakeLists.txt
...
set(PYBIND_VERSION "v2.13.6" CACHE STRING "the Git tag for pybind11")

The configuration preset works fine:

$ cmake --preset pybind --fresh -DPYBIND_VERSION=v2.11.0
Preset CMake variables:
  ...

-- The C compiler identification is GNU 13.1.0
...
-- pybind11 bindings (pybind version v2.11.0)
...

But workflow (that performs the configuration and a build step) does not accept the option:

$ cmake --workflow --preset build_pybind -DPYBIND_VERSION=v2.11.0
Unknown argument -DPYBIND_VERSION=v2.11.0
...

It is CMake version 3.26.2.

10

cmake --workflow supports very few options. It does not support adding -D options.