cmake --build --preset=default from non-SOURCE_DIR

Hi there, first of all I wanted to say the new “presets” feature is amazing and definitely has the possibility to fundementally change how we interact with CMake in the future.

However, for some reason the following usages do not seem to work and we are basically required to run the cmake command from the CMAKE_SOURCE_DIR only.
cmake --build --preset=default path-to-source
cmake --build --preset=default path-to-existing-build
cmake --build path-to-source --preset=default
cmake --build path-to-existing-build --preset=default
cmake --build --preset=default -S path-to-source
cmake --build --preset=default -B path-to-existing-build
cmake --build --preset=default -S path-to-source -B path-to-existing-build

If I manually cd to the CMAKE_SOURCE_DIR the following works:
cmake --build --preset=default

The equivalent of the above for the configure step all work though:
cmake --preset=default path-to-source
cmake --preset=default path-to-existing-build
cmake --preset=default -S path-to-source
cmake --preset=default -B path-to-existing-build
cmake --preset=default -S path-to-source -B path-to-existing-build

I believe the --build behavior should match the configure behavior. Am I missing something? I would think the -S argument or path to source would function similarly to the -C option in make/ninja. I might also suggest that a simple enviornment variable would be a good way for interactive users where I could simply export CMAKE_SOURCE_DIR and have it respected in all the various cmake utilities versus passing command line parameters.

I did look and I did not see this reported before.

*Edit: angle brackets didn’t show up correctly, so I removed them

Cc: @kyle.edwards

Just checking in. Looking to at least confirm whether or not this is expected behavior or a bug.

The build presets were the creation of Sam Freed from the Visual Studio team at Microsoft. I’d tag them here, but I don’t know if they’re on Discourse or not.

I can’t seem to find the discussion, but earlier this year Craig Scott and I among others were discussing having an optional system-wide preset, vs. environment variables, etc.

I also run into this issue, so I think it’s a topic among multiple preset users here.

I do think most of my concerns would be addressed by a simple ‘change working directory’ flag similar to Make’s or Ninja’s. It allows you to easily execute the commands regardless of current working directory. In addition, it is easy to use in aliases and the like with something as simple as:
ninja -C ${SRC_DIR:-.}

I am not 100 percent what you mean by a system wide preset. But for our projects we use a machine for many purposes so it doesn’t sound like it would apply. But I may be misunderstanding something.

The other one I feel is missing would be a user presets file in a home directory. We have many cmake projects that I would want to share some presets between. In my current situation I have to copy them into each projects location.

With all that said I think the preset stuff is super useful and really appreciative of all the current work done on it so far.

Issue 21331 is probably what you’re looking for.

Is there any news on this topic?

I looked at the discussion but using include from a top-level CMakePresets.json file does not seem to work with build presets.

For the following project:


CMakePresets.json (include: 3rdPartyLibrary/CMakePresets.json)
    |
    | ----- 3rdPartyLibrary
                     |
                     | ------- CMakePresets.json (confgurePreset: default, buildPreset: default)

From top level I can configure a build:

cmake --preset=default

But I cannot build:

cmake --build --preset=default

I have also been looking for way to retrieve property values from the configPreset like binaryDir. I could parse the file with other tools, but it would be great if I could do it through cmake.

To my knowledge, build presets work fine with include. You might not have specified things correctly. I suggest you open a new discussion thread with a minimal set of presets files that demonstrate your problem.