Fields listed below are ignored. The only way I found to specify a generator is via cmake.generator in settings.json.
Field preferredGenerator in cmake-kits.json is ignored.
Field cmake.preferredGenerators is settings.json is ignored.
Can I get some more information on what generators you are trying to use? What platform are you one? What CMake version are you using?
Sure.
Let's say "Ninja" generator: "preferredGenerator": { "name": "Ninja" } in cmake-kits.json
I'm on Windows 10 64-bit with latest updates.
CMake version 3.9.3.
There's a priority the CMake Tools will decide on a generator:
cmake.generator setting.cmake.preferredGenerators settingpreferredGenerator on the active kitWhat do you see from CMake Tools when you try to configure? Is it failing to choose a generator? Is it choosing a generator that you don't want? Can you show the debug log from when you try to configure and it fails?
It just selects whatever it wants. When I didn't use cmake.generator, it used to select the Visual Studio one. After I used cmake.generator with Ninja (and then removed), it now defaults to Ninja.
For example:
[driver] Switching to kit: Visual Studio Community 2017 - x86
[cms-client] Configuring using the "Ninja" CMake generator
@KoeMai has any of your generator work affected this issue?
my unit test for the 'not configured yet' pr is using different generators. but there was a race condition. I think if PR is mainline then it should work.
My generator is not selected as well. I want to use Visual Studio 9 2008:
{
"cmake.generator": "Visual Studio 9 2008",
"cmake.preferredGenerators": [
"Visual Studio 9 2008"
],
}
I even cleared the cmake-kits-json to only contain this one:
[
{
"name": "VisualStudio 2008",
"visualStudio": "VisualStudio.9.0",
"visualStudioArchitecture": "Win32",
"preferredGenerator": {
"name": "Visual Studio 9 2008"
}
}
]
When I start the configure process, I receive
[proc] Executing cmake.EXE --no-warn-unused-cli DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -Hd:/src -Bd:/src/build
[cmake] Not searching for unused variables given on the command line.
[cmake] -- Building for: Visual Studio 14 2015
[cmake] -- The C compiler identification is MSVC 19.0.24215.1
In the integrated terminal (powershell) directly inserting -G "VisualStudio 2008" works.
I'm also having this problem. I'm on Windows 10 x64. The generator option is ignored in all situations for me. I've tried setting preferredGenerator in cmake-tools.json, cmake.preferredGenerator in settings.json, and cmake.generator in settings.json. All are ignored.
When executing cmake to configure, the -G option is never passed.
Sorry for the delay on this issue. I've been busy with a few other projects.
Once #437 is in a release, I'll check back on the state of this issue.
I'm having exactly the same experience as @zenakuten ... This quick fix worked for me: Just set the generator in the "Configure Args" e.g. "cmake.configureArgs": ["-GNinja"].
I had trouble getting the extension to select the Visual Studio generator I'd specified for my kit.
I discovered that there are default values for cmake.preferredGenerators ("Ninja", "Unix Makefile") and if either of these is present in the system, it will select them over the one you've specified for the kit.
I guess the term _preferred_ should have made it obvious to me, but I didn't notice this setting and also assumed that specifying a generator for a kit would override other "fallback" settings.
In the end I overrode the default value of cmake.preferredGenerators with an empty user setting, and configured the generator explicitly for each kit.
Having this issue as well. Visual Studio 2017 uses Ninja on my system, which is broken. ninja.exe is on my PATH for support for cross compiling on other platforms (namely Android). It should not be used as a makefile generator for Visual Studio generators. This is busted.
I have the same problem trying to select Unix Makefiles over Ninja, I tried everything (together or apart, nothing worked):
{
"cmake.preferredGenerators":[],
"cmake.preferredGenerators":[
"Unix Makefiles",
"Ninja",
],
"cmake.generator": "Unix Makefiles",
"cmake.configureArgs": ["-G", "Unix Makefiles"],
}
In the end the only solution that worked for me was to select No active kit.
Hello
I have the same problem as well as of 1.1.3 : I need MSBuild generators because I dislike the hassle of setting the command-line environment before configuring and building my project, which is only needed when using Ninja.
On a side note @cdcseacave , please note that Visual Studio itself (not vscode) uses Ninja, not MSBuild, when opening CMake-based projects (natively). This must have generated some internal frictions between Microsoft teams :)
(and Ninja works pretty well and pretty fast)
Thanks again for this extension that makes it really easy to work with CMake projects. KUDOS!
For me, Ninja was also being used even though I did not want it. Whenever I used Ninja, I was getting Error required internal CMake variable not set, cmake may not be built correctly. errors (reinstalling CMake and downloading new Ninja did not help).
Setting "cmake.preferredGenerators":[] helped.
Can confirm with version 1.1.3 on OSX Mojave. No matter what I specify in the configuration files only Ninja is ever used when building the project.
I ran into this as well. No matter what is configured in settings (local/workspace) or what is in cmake-tools-kits.json, whatever I set in preferred generators or in cmake.generator is ignored and "-G" param is never passed to cmake executable.
It worked for a while but then I don't know how I broke it and I can't get it to work again.
So now I have to set "cmake.configureArgs" explicitly.
I also ran into the problem that Ninja was used, even though I chose the Visual Studio 16 2019 kit. Setting "cmake.preferredGenerators":[] helped, but that's really unintuitive in my opinion.
I hit it today on MacOS. Edited ms-vscode.cmake-tools-1.2.3/schemas/variants-schema.json to change the Ninja to Unix Makefiles which it did not like at all, but then I put it back to Ninja and everything started working again. Reinstalling, deleting the directory, etc. had all been unsuccessful.
The order of preferred generators in the different configuration files is
cmake.generator settingcmake.preferredGeneratorspreferredGeneratorOf you set cmake.preferredGenerator to [] it should use the kit defined preferred generator. If no cmake.generator is Set.
The CMake Extension forwards the generator name via server-api interprocess communikation. This ist why -G ... does not work in server Mode.
The CMake Extension checks the generator needed executable for valid executable.
This may fail in some of the before described cases.
In this issued are many problems discussed, if these problems are still present we could discuss them better in separate issues.
They were being ignored. It felt like something was caching incorrectly.
I hit the problem again, different computer. All the generator settings were ignored. Switching to another workspace (different clone of same repo) did not have the problem, switching back did. Deleting contents of build directory did not help. Deleting the build directory itself and recreating it seems to have worked.
FYI - I was running into the same problem where cmake.generator, cmake.preferredGenerators etc. were being ignored. I found that using Ctrl-Shift-P and executing Developer: Reload Window caused the settings changes to take effect.
FYI - I was running into the same problem where cmake.generator, cmake.preferredGenerators etc. were being ignored. I found that using Ctrl-Shift-P and executing Developer: Reload Window caused the settings changes to take effect.
This is exactly what worked for me. I had already changed cmake.generator to "Unix Makefiles" but vscode was stubbornly using Ninja even when I deleted everything and reconfigured. Reloading with Developer: Reload Window worked fine: subsequent configures used makefiles.
This issue should be fixed in version 1.4.
@travisdowns, the issue you're seeing is #1127.
Most helpful comment
I have the same problem trying to select
Unix MakefilesoverNinja, I tried everything (together or apart, nothing worked):In the end the only solution that worked for me was to select
No active kit.