"Set Build Target" list is empty after configure even though "Project Outline" pane contains targets

[andrewmcdonald-oxb]

Brief Issue Summary

CMake Tools has been working fine for me for ages, but suddenly it's started exhibiting a problem this afternoon. Normally the option to pick a build target would be populated with items from CMake, but now it is always empty. This happens even after I configure from within VS Code. In this situation the Project Outline pane is populated with items correctly, so something is working differently in the target picker type-in. Is there some logging I can enable to debug this? Perhaps some cache files somewhere have become corrupted. I've restarted VS Code, rebooted the machine, even deleted and recreated my build folders to no avail.

Expected:

1. Configure with VS Code
2. Examine Project Outline pane and see it is correctly populated with targets
3. Click build target button on bottom toolbar, or use "CMake: Set Build Target" from command palette
4. Popup should be populated with target names

Apparent Behavior:

1. Configure with VS Code
2. Examine Project Outline pane and see it is correctly populated with targets
3. Click build target button on bottom toolbar, or use "CMake: Set Build Target" from command palette
4. No targets are shown and type-in accepts free text

CMake Tools Log

Contains sensitive info. If pointed at some further logging I can investigate further on my end.

Platform and Versions

• Operating System: macOS Catalina 10.15.6
• CMake Version: 3.18.4
• VSCode Version: 1.50.1
• CMake Tools Extension Version: 1.4.2
• Compiler/Toolchain: Apple Clang 11.0.3

Additional Information

I do see this in the CMake output, but according to the reported issue it should have no impact:

[cmakefileapi-parser] Code model version (2.1) of cmake-file-api is unexpected. Expecting (2.0). IntelliSense configuration may be incorrect.

[andreeis]

Thank you for reporting this. I am not able to reproduce, although I didn't have the exact versions and conditions you mention. I will try again later on a mac, cmake 3.18, etc... Until then, do you remember any specific operation you might have done the day this started to happen? Change of generator, of kit, a setting...

Can you try a different clone of your project, your project on a different computer, a new project (if you don't have anything create a small one via "quick start"). Make sure the logging level is verbose: write this in .vscode/settings.json: cmake.loggingLevel: "debug" This will ensure maximum hints in the CMake Tools output channel.

Also, I know you said you tried deleting the build folder and a restart. Make sure you delete the build folder and then you do a restart (close reopen VSCode).

Other things you can try to give us hints is to apply vsix-es different than the current published version 1.4.2. Trying 1.4.1 may help in finding if this is a regression. Trying any recent vsix created on this GitHub repo for each PR that gets merged would help in finding if we fixed this problem for the 1.5 release.

We'll figure it out.

[andrewmcdonald-oxb]

Thanks @andreeis. I started hearing that colleagues were experiencing the same issue, which showed it wasn't just some local cache problem on my laptop. I started looking at our recent source repo history and narrowed it down to a particular commit where someone had added some CMake lines. It boils down to this:

string( TOUPPER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE )
if( CMAKE_BUILD_TYPE STREQUAL "DEBUG" OR CMAKE_BUILD_TYPE STREQUAL "COVERAGE")
  # ... CMake code ...
endif()

I guess CMake Tools doesn't like having the value of CMAKE_BUILD_TYPE changed even if it's just capitalisation - case-sensitivity somewhere? Changing the CMake codee to use a separate temporary local name seems to fix the issue.

There is perhaps something that could be done in VS Code to catch this. Upping cmake.loggingLevel I sometimes saw this when it went wrong:

[driver] Failed to configure project
[extension] [5482] cmake.configure finished (returned -1)

But there was no other message in the IDE - shouldn't an error toast or something be displayed? That might have caught the issue sooner on our end. Oddly though, even in cases where it was going wrong, it would sometimes claim a return code of 0 instead. I'm not sure whether this is coming from CMake itself or the extension.

[andreeis]

Interesting. Thanks for the cmake snippet code, we will try that and I hope we'll be able to reproduce what you're seeing. Then we'll be able to find a fix and maybe also a workaround for you until the fix is released.

[Jasper-Li]

Do you solve this issue? I have the same issue, too.

[andrewmcdonald-oxb]

Hi @Jasper-Li , yes my situation this was solved as above - the problem was our CMake code manipulating the case of CMAKE_BUILD_TYPE's contents. Is that also happening in your CMake code?

I think this issue remains open to investigate the possibility of detecting this problem earlier and offering appropriate error messaging, and whether the intermittent configure failures were related.

[Jasper-Li]

Hi @andrewmcdonald-oxb , I changed CMAKE_BUILD_TYPE setting to "Ninja" or "Visual Studio 17 2022", it still has the issue.

I get source code of vscode-cmake-tools, add more logs manually. There is an exception in file src\drivers\driver.ts

Invalid value to convert to cmake value: 'files.associations'

back trace: src\util.ts, cmakeify src\drivers\driver.ts generateCMakeSettingsFlags src\drivers\driver.ts configure

I have no setting on 'files.associations', and failed to find where it comes from. Sadly, I've never write Typescript code before. Do you know any developer could solve this issue?

By the way, all things works successfuly on another PC, which has the same vscode + CMake Tools settings. Maybe the issue is related to environment.

[Jasper-Li]

Hi,everyone, I solve my issue! There is bad configuaration of 'files.associations' in vscode .workspace file. I delete these configurations and make the .workspace file clean, so cmake works well. Unfortunately I forget backup it before deleting.

[rewqazxv]

In my case, the target list became empty when CMAKE_BUILD_TYPE was changed (either TOUPPER or set to a new value). Adding either of the following lines to CMakeLists.txt can reproduce the problem:

set(CMAKE_BUILD_TYPE no_type)
string(TOUPPER ${CMAKE_BUILD_TYPE} CMAKE_BUILD_TYPE)

[jpfeuffer]

I have the same issue even though I removed all of the CMAKE_BUILD_TYPE statements (+reopened, reset cache, reset plugin state) so I think this is not the only thing that made the list stop working.