Different build directories for different build types

[Sarna555]

Brief Issue Summary

Different build directory for different build type

Expected:

For instance,
I got Debug and Release build types.
I want to build Debug in "Build-Debug" and Release in "Build-Release" directories.
Of course I want it preconfigured without having to change this every time I change build type.

Other Notes/Information

Sorry if it's possible and I haven't found it.

[vector-of-bool]

Check here. Set cmake.buildDirectory using ${buildType}.

[Sarna555]

Thanks for the quick response!

It partially solves my problem because I got two Debug and two Release configurations and I wanted to have it all in separate build directories if possible.
The most natural way (at least for me) would be to have additional option in Variants, buildDirectory
For instance

buildType:
  default: debug
  choices:
    debug:
      short: Debug
      long: Emit debug information
      buildType: Debug
      buildDirectory: ${workspaceRoot}/build-debug
    release:
      short: Release
      long: Optimize generated code
      buildType: Release
      buildDirectory: ${workspaceRoot}/build-release
    asan:
      short: Asan
      long: Instrument with Address Sanitizer
      buildType: Asan
      buildDirectory: ${workspaceRoot}/build-asan
    tsan:
      short: Tsan
      long: Instrument with Thread Sanitizer
      buildType: Tsan
      buildDirectory: ${workspaceRoot}/build-tsan

[vector-of-bool]

That is also supported, but using this ${variant:something} syntax.

[nsubtil]

I was about to file a similar issue, this is really helpful.

I'm having trouble figuring out how this interacts with launch.json, however. Is it possible to get the path to the current CMake build directory in launch.json via variable substitution somehow? Is there some documentation on the list of vscode-cmake-tools commands that can be used with the ${command:} syntax in launch.json?

[vector-of-bool]

In general any palette command works with ${command:} syntax, but the only useful one CMake Tools provides is cmake.launchTargetPath. Support for additional substitution commands is possible, and worthy of a separate GitHub feature request ticket.

The variable substitutions supported by CMake Tools in settings.json and what is in launch.json may have similar syntax, but they are almost entirely disjoint and implemented completely separately.

[Sarna555]

That is also supported, but using this ${variant:something} syntax.

Sorry for being a pain but I have no idea how to use it 😄

[nsubtil]

Filed #564 requesting variable substitution for cmake.buildDirectory.

As a follow-on dumb question:

In general any palette command works with ${command:} syntax

I've always had trouble figuring out the appropriate ${command:} syntax for a palette command. Is there a list somewhere?

[bobbrow]

@Sarna555, ${variant:something} should just be ${variant:buildType} in the case of the yaml you posted above.

Another example:

Using ${variant:testVariant} resolves to foo when "Foo" is selected

[xgdgsc]

Is it possible to set "${workspaceRoot}/build-${buildType}" by default? This is the only thing that I find inconvenient switching from other IDE.

[bobbrow]

Do you mean you want that to be the default for all workspaces? You should be able to set it as the default by editing the "User" setting for it:

[xgdgsc]

Thanks. I know that. I just think it might be worth considering to make it the default option after install this extension.

[dmsteck]

@xgdgsc Agree. This is such a basic feature and it should really be the default behaviour of the extension.

For example, CLion uses cmake-build-${buildType}, where the build type is also lowercased.

[bobbrow]

The trouble is that some generators only need a single configure step because they generate all variants up front. If the default were based on the buildType, then those generators would have to generate their build rules in N different places even though they are all basically copies of each other.

VS Code doesn't give us an way to have conditional defaults, so this is the least disruptive default.