Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake Tools 1.4.0 doesn't define CMAKE_BUILD_TYPE in a project's build directory's CMakeCache.txt #1298

Open
drfknoble opened this issue Jun 9, 2020 · 10 comments
Labels
enhancement an enhancement to the product that is either not present or an improvement to an existing feature Feature: configure
Projects
Milestone

Comments

@drfknoble
Copy link

Brief Issue Summary

I am using Visual Studio Code and CMake Tools to build a simple C++ project using OpenCV. The project relies on OpenCV's opencv_world430d.dll and OpenCV_world.dll files. To copy them to the build and install directory, I use an if statement to check whether the CMAKE_BUILD_TYPE matches either Debug or Release; then I define a variable equal to the path to the corresponding debug or release dll. Lastly, I use a custom command to copy the files to the build directory and install them to a desired install location. The problem is, CMAKE_BUILD_TYPE is not defined - even though I've configured the project and selected a Debug configuration.

Expected:

If build type is Debug, the syntax if(${CMAKE_BUILD_TYPE) MATCHES Debug) should return true; else, if build type is Release, the syntax if(${CMAKE_BUILD_TYPE) MATCHES Release) should return true.

It is expected that CMAKE_BUILD_TYPE is defined as either Debug or Release.

Apparent Behavior

CMAKE_BUILD_TYPE is not defined.

Platform and Versions

  • Operating System: Windows 10
  • CMake Version: 3.17.3
  • VSCode Version: 1.45.1
  • CMake Tools Extension Version: 1.4.0
  • Compiler/Toolchain: Visual C++ 2019

Other Notes/Information

Looking in the project's build directory's CMakeCache.txt file, CMAKE_BUILD_TYPE is not included. When I use Visual Studio 2019, the project behaves as expected and CMAKE_BUILD_TYPE is included in the CMakeCache.txt file.

@drfknoble
Copy link
Author

If you manually set the preferred generator to be "Ninja", then CMAKE_BUILD_TYPE is defined in the CMakeCache.txt file.

If no preferred generator is specified, Visual Studio is used as the generator and it doesn't specify CMAKE_BUILD_TYPE in the CMakeCache.txt file.

Given that Visual Studio may be the default for a lot of people, it'd be good if it, by default, added CMAKE_BUILD_TYPE to CMakeCache.txt. I'm not sure if it's a bug, a problem with my installation, or something I should do (but didn't know to do). Perhaps if someone can comment, then we can be sure which of these it is.

@jakoch
Copy link

jakoch commented Jun 10, 2020

Hi!

I think CMAKE_BUILD_TYPE isn't set by default in this case, because CMake supports two types of generators: single-configurations (makefiles, nmake) and multi-configurations (IDEs).

I suggest to add the following lines to settings.json.
This should then update your CMAKE_BUILD_TYPE accordingly and set it as -D CLI option.

"cmake.configureSettings": {
   "CMAKE_BUILD_TYPE": "${buildType}"
}

With this in the CMakeListst.txt to see, if var is set:

message(STATUS "CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE}")

@db4
Copy link

db4 commented Jun 14, 2020

Looks like the problem is the CMake generator: for older CMake Tools it was Ninja but for 1.4.0 it's Visual Studio XXXX. The latter is a multi-configuration generator so CMake does not define CMAKE_BUILD_TYPE for it (CMake generator expressions supposed to be used instead)

I also need CMAKE_BUILD_TYPE in my build to I'm trying to use Ninja generator as I did before. No luck yet - any related vscode settings (cmake.preferredGenerators etc.) are just ignored. Any idea how to do that?

@bobbrow
Copy link
Member

bobbrow commented Jun 16, 2020

@db4, Are you saying that the Ninja generator is not defining the CMAKE_BUILD_TYPE? Have you reloaded the window/extension since you changed your generator? Sometimes the settings change doesn't automatically get applied. That's something we're investigating. #1127

@db4
Copy link

db4 commented Jun 16, 2020

@db4, Are you saying that the Ninja generator is not defining the CMAKE_BUILD_TYPE?

Quite the opposite: Ninja generator defines CMAKE_BUILD_TYPE, Visual Studio XXXX does not.

@bobbrow
Copy link
Member

bobbrow commented Jun 16, 2020

So are you saying you can't get the extension to pick Ninja again? Did you set the cmake.generator or cmake.preferredGenerators settings?

@andreeis andreeis added more info needed More info is needed from the community for us to properly triage and investigate. Feature: configure labels Jun 18, 2020
@db4
Copy link

db4 commented Jul 3, 2020

So are you saying you can't get the extension to pick Ninja again? Did you set the cmake.generator or cmake.preferredGenerators settings?

Well, I cannot reproduce the issue anymore - after upgrade to 1.4.1 and some cleanups cmake.generator=Ninja works as expected.

@xylr117z4
Copy link

xylr117z4 commented Jun 23, 2021

VS Code has added a setting for Cmake which sets the build type on multi config generators (the default generator.)

if you open File > Preferences > Settings and search "CMAKE_" or "CMAKE_BUILD_TYPE" it'll be the first option to appear.

image

It'd be nice if this were the default, but well I'm not sure where we'd bug them about it... and well I can't be bothered to do that.

@xiaohaoo
Copy link

xiaohaoo commented Jul 8, 2023

VS Code为Cmake添加了一个设置,它在多配置生成器(默认生成器)上设置构建类型。

如果你打开文件>首选项>设置并搜索“CMAKE_”或“CMAKE_BUILD_TYPE”,它将是第一个出现的选项。

image

如果这是默认的就好了,但是我不确定我们会在哪里打扰他们……我可不想这么做。

Good.

@benmcmorran benmcmorran added enhancement an enhancement to the product that is either not present or an improvement to an existing feature and removed more info needed More info is needed from the community for us to properly triage and investigate. labels Jul 11, 2023
@benmcmorran benmcmorran added this to Triage in 1.16 via automation Jul 11, 2023
@benmcmorran benmcmorran added this to the 1.16 milestone Jul 11, 2023
@benmcmorran benmcmorran moved this from Triage to To do in 1.16 Jul 11, 2023
@benmcmorran
Copy link
Member

We'll evaluate changing the default value of this setting in the 1.16 extension release.

@benmcmorran benmcmorran modified the milestones: 1.16, 1.17 Oct 4, 2023
@gcampbell-msft gcampbell-msft added this to Triage in 1.17 via automation Nov 20, 2023
@gcampbell-msft gcampbell-msft removed this from To do in 1.16 Nov 20, 2023
@gcampbell-msft gcampbell-msft modified the milestones: 1.17, On Deck Nov 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement an enhancement to the product that is either not present or an improvement to an existing feature Feature: configure
Projects
Status: Pending Prioritization
1.17
Triage
Development

No branches or pull requests

9 participants