USER HELP WANTED: Beta and documentation testing

[vector-of-bool]

HELP WANTED

Click here for much more information, including a "What's changed"

I've been busy for a few months on a lot of things, both online and in "real life."

I've often mentioned that I've been on a large rewrite/refactor for the extension, and I'll have to admit that it's closer to the former, as a bit of functionality changed. Some additions, some removals.

But it has been far too long, so I'm officially releasing a "beta" release of the 0.11.0 release.

A lot has been changed/tweaked, and I need user feedback.

If you're feeling adventurous, please download and install the beta release and/or check out the beta documenation.

Use this ticket to provide general feedback, but please create a new issue for bugs and requests for the beta version.

No need to do anything fancy: Just install the beta and work around with your existing projects like you normally would.

Update: Fifth beta is out. The link above has been modified to point to it.

[omaralvarez]

I have been trying the new version, and my main problem is that include files are still not automatically detected and added to the IntelliSense include path. There is another extension that tries to do this, CMake Toools Helper, but for me it does not work properly. It would be nice if with 1.0 this extension would include support for that.

[el-robo]

It fails to initialize with the error 'invalid kits' but that means I can't use the commands such as edit kits since the extension is no longer loaded.
I did edit the kits file after the first start - since it asked. But I can't find it now to correct any issues.

edit: was able to find the file, but the result stays the same when removing it and re-scanning for kits.

[cmazakas]

Yeah, what @omaralvarez said. The CMake tool could easily examine the Cache and append the include paths. I have to do it manually now.

One thing I've noticed is that the CMake server has no way of being shutdown or restarted. For example, if I wanna delete my build folder while the extension is running, the locking mechanism on Windows makes anything impossible so I have to close VS Code and then reopen it.

Also, default initialize the build type to Debug instead of Unknown.

[vector-of-bool]

@eldadroobol, good find on bad kits. I'll get a fix for that. For now, you can open up the kits json file manually to fix it. It's stored in %AppData%/CMakeTools on Windows and ~/.local/share/CMakeTools on *nix.

@LeonineKing1199, what do you need to delete the build directory for? Does Clean configure or Clean rebuild not do the trick?

Also, regarding a default build type: Pull #277 should load up a default variant.

[vector-of-bool]

@eldadroobol could you open a new issue for that one? I'm taking a look now but just want to keep it tracked separately. Could you include the content of your kits file that makes it do bad? What kind of errors are you seeing?

[vector-of-bool]

Just published a second beta release. It should fix the issue with kits, as well as some bugfixes.

[sterin]

Testing a simple hello world project using beta 2, latest vscode and latest macOS.

Any attempt to configure results in the following error message:

Error: command 'cmake.setVariant' not found

Similar error occur when trying to run any other cmake-tools command.

[cmazakas]

@LeonineKing1199, what do you need to delete the build directory for? Does Clean configure or Clean rebuild not do the trick?

Unfortunately, not quite. Sometimes I need a full on rebuild of the cache and all relevant CMake files. A lot of times it's just easier to burn 'n' purge the build directory.

[vector-of-bool]

@LeonineKing1199 and @sterin, I want to follow up, but could you each create a new issue for your specific problem and mention this issue (to generate a new link)?

I want to keep this thread short and general and make sure that we're not spamming notification emails to everyone who comments.

Thanks!

[el-robo]

@vector-of-bool made an issue (#282)

[el-robo]

The startup issue has indeed been resolved in beta2 btw.

[MathiasMagnus]

@omaralvarez If you are using Microsofts C++ extension, once you populate the compileCommands setting inside c_cpp_properties.json, then there will be no need to populate it, since it will pick up the correct includes from CMake. However, note that IntelliSense will kick in (hover over non-STL types will work), but code navigation is not yet hooked up to use compileCommands. I think it's best to wait until they hook up the code navigation database to also use it.

[MathiasMagnus]

@sterin Me too. CMake Tools 0.11.0-beta2, VS Code 1.19.1 and using MS Build Tools 15.5.2, no big brother VS installed. CMake Tools 0.10.x found MSVC alright, but this new version does not show the build environment selector.

None of the new features light up. The commands show in the Command Palette, but they all throw errors. I cannot configure because of the aforementioned

Error: command 'cmake.setVariant' not found

neither do I see the kit selector...

[KoeMai]

@MathiasMagnus can you provider a develop Mode log file of vscode in a new issue.

[MathiasMagnus]

How can I do that? I turned on "cmake.loggingLevel": "debug", but I can't see where the logs are going.

[KoeMai]

I use in the most cases this way:
Menu -> help -> toggle developer Tools - > goto tab console -> rights click into messages -> Save as...

[vector-of-bool]

To anyone having trouble on macOS, I've found the bug and have a fix in the works for it. See #278.

@MathiasMagnus, setting loggingLevel to debug should make the debug logs appear in the regular output channel. Debug lines won't be annotated differently, but they'll be there. The devtools console has the debug logs by default with the level annotated.

[vector-of-bool]

Just pushed a beta3. Should now work on macOS, plus there are some updated docs on variable expansion for configuration options.

[vector-of-bool]

And now, the fourth beta is out. It should fix a bunch of issues with using Visual Studio kits. This might be the last beta (barring any big new bugs) now that macOS, Linux, and Windows all seem to be working for the most part.

[MarioLiebisch]

For me the VSIX installer fails with an Microsoft.VisualStudio.ExtensionManager.InvalidExtensionManifestException (triggered by Version attribute of Identity). Guess this might have to do with locales (since my Windows is German), but haven't seen that before with other packages. (Edit: I'm on 1.20.0-insider)

[bbosnjak]

Kits approach is interesting, but for me not practicable.
I am using this extension for embedded device development. I have several different compilers and compiler configuration is together with project in toolchain file.
It would be great to have some kind of "NONE" kit and leave it to the "cmake.configureSettings" CMAKE_TOOLCHAIN_FILE to define toolchain file. Note also that "${workspaceRoot}" in CMAKE_TOOLCHAIN_FILE is not working any more (issue #292).

[doxxx]

I tried out beta 4 on Windows 10 with Visual Studio 2015 & 2017 installed. It detected all the kits but then spits out two errors:

• Unknown CMake generator "Unix Makefiles"
• Unknown CMake generator "Ninja"

If I click the button at the bottom to select a kit, I get another error:

• Unable to determine CMake Generator to use

The CMake output window contains the following:

[variant] Loaded new set of variants
[kit] Loading new set of kits
[kit] Successfully loaded 8 kits
[cms-client] None of preferred generators available on the system.
[rollbar] Unhandled exception: Unhandled Promise rejection: selectKit Error: Unable to determine CMake Generator to use {}

[doxxx]

I tried overriding cmake.preferredGenerators in my VSCode user settings with the following:

"cmake.preferredGenerators": [
    "Visual Studio 14 2015 Win64"
]

After reloading the window, CMake Tools is able to initialize itself and I can click the kits button to select a different kit.

EDIT: However, I got an error when trying to select a configuration. It was something rather unhelpful like "false != true".

I changed cmake.preferredGenerators to an empty list and reloaded the window, which seemed to fix the problem.

[doxxx]

I just noticed that the detected kits are a bit weird:

Those are some odd combinations with arm, x86 and amd64 for Visual Studio 2015.

[MathiasMagnus]

Nothing is weird about that. Those are cross-compilers if you have them installed. amd64 is 64-bit comiler targeting 64-bit machines, x86 is the same but with 32-bits, the underscore variants have their first part indicating the compiler (host) architecture and the second part indicates the target (resulting binary) architecture.

I would expect these to light up as part of normal behavior.

[cmazakas]

I think the weird ones are the x86_arm architectures. I've never heard of an x86 ARM processor before :P

[doxxx]

@LeonineKing1199 No, what @MathiasMagnus says makes sense. x86_arm means the x86 32-bit compiler is being used to produce ARM binaries.

I do think that the kit names could be formatted/worded better to make that distinction clearer.

[decimad]

CMake Tools Helper is not really required anymore, as the C/Cpp Tools can now parse the "compile_commands.json" emitted by select cmake Generators.

[omaralvarez]

C/Cpp Tools can now parse the "compile_commands.json" emitted by select cmake Generators

Could you be more specific? Which generators are supported? Which code and cpptools version? I have lost a lot of time with this, and would like to nip it in the bud.

Edit: I have finally made this work. For anyone looking for an answer to this:

You need a generator that creates a compile_commands.json and then you need to specify its path in c_cpp_properties.json with "compileCommands": "${workspaceRoot}/build/compile_commands.json". After that build and open a source file, and no include errors should be present.

[Kehom]

Just some feedback.
I have (on my Windows machine) both Visual Studio and MinGW toolkits, which are properly detected by CMake Tools Scanner. I had to manually set the preferredGenerators otherwise nothing would work (everytime giving me an error telling that no generator was found).

But the thing that is really bugging me is the fact that if I switch toolkits, the generator is not. It will always pick the first entry in the preferredGenerators list. I noticed that when I selected to use GCC but then the code was built with Visual Studio. Aren't the generators directly tied to the selected toolkit? Is the generator setting really necessary when there is a "toolkit selector"?

With some more testing:
In the workspace settings I set to use "MinGW Makefiles" generator but it still used Visual Studio. When I moved the MinGW to the top of the preferred list, then I was able to generate the executable with GCC.
Now, another problem here is that with this setting if a configure the generator inside the workspace settings to Visual Studio (and obviously switch the toolkit), the build process fails telling me MSBUILD : error MSB1009: Project file does not exist..

If you want to know why I'm switching between toolkits, here is the reason:
I'm profiling (comparing techniques) some code and I want to make sure the results are similar throughout the compilers.

Thanks for your attention and for making CMake Tools available

EDIT:
I have performed some more tests and found out that the error (project file does not exist) I got is because the list of build targets is different when switching the toolkit. I have been able to switch between toolkits (and build) but I have to change the generator in the workspace settings to match the desired toolkit.

[MathiasMagnus]

I have similar experiences, although it's less of a hassle for me. I'm not switching between configurations, but have both Ninja and MS Build Tools installed. I always build with MSVC (not hooked up Clang up yet), and even though the default preferredGenerator for MSVC compilers are the Visual Studio generators, it keeps using Ninja, because that is at the top of the global config. I'd guess that the Kit preferences are there to override the global setup... for me it's fine using Ninja, after all it's faster than MSBuild, but it might cause aggravation to others.

[wichert]

I see a different issue: trying to configure CMake always results in this error:

[rollbar] Unhandled exception: Unhandled Promise rejection: setVariant Error: spawn EACCES {}

[KoeMai]

Can you create a new issue with a log output? This makes it easier to identify the problem and handle the bug fixing.

Menu -> help -> toggle developer Tools - > goto tab console -> rights click into messages -> Save as ...

[vector-of-bool]

Going to shameless plug here that I have an open call for contributors. Please send help!

[MaximeDV]

Hello. I've seen that CMakeTools still uses workspaceRoot variable that is deprecated in VSCode. VSCode now uses workspaceFolder.
Thanks,
Max

[vector-of-bool]

Hey all! After several months and lots of help, I've finally posted the beta5.

Even though it's just another follow-up beta release, it's a landmark change:

• There's now a small team behind the development (@KoeMai, @Randshot, @ytimenkov, and myself). I hope that this will break up the long periods of radio silence that I tend to produce, as well as offload some of the bug triage and investigation/fixing.
• There's much more thorough testing, so big breaking changes will rise to the surface quickly before they become a problem. There's still quite a way to go, though.
• There's now proper CI in place in Travis and AppVeyor, so all commits and PRs are running through the testing gauntlet before merging.

With this new infrastructure in place, I feel confident that 0.11.0 is just about ready for prime-time. I'm hoping to bring the testing even further before finalizing 0.11.0, and then on to the big one-dot-zero. There's a lengthy feature backlog that I want to get started on, but I need to get 0.11.0 in the hands of users first just to make sure we're in a sane world.

[decimad]

This is great news!
I noticed that reloading the window will always end up in a state "Unconfigured" in my project, even if the project was configured already. This also leads to no build target being selected.

[s-martin]

Great, thanks for your effort, guys!

[vector-of-bool]

@decimad, would you open a new issue for that problem?

[xgalaxy]

Been using the new build on MacOs and it is working great.

The only thing that is maybe a little cumbersome is if I have LLVM installed (side-by-side XCode) via Homebrew or manually the kits configuration doesn't appear to allow you to set the LDFLAGS or CPPFLAGS to that alternate compiler. So you have to do it with CMAKE configuration args in your user settings (because it doesn't make sense to put it in your workspace/project settings since its my machine and not others).

Here is an example of what Homebrew says:

To use the bundled libc++ please add the following LDFLAGS:
  LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib"

For compilers to find this software you may need to set:
    LDFLAGS:  -L/usr/local/opt/llvm/lib
    CPPFLAGS: -I/usr/local/opt/llvm/include

I guess this could be done with a toolchain file?