vscode-cmake-tools
vscode-cmake-tools copied to clipboard
microsoft
Option to disable automatic kit detection
Is it possible to add a cmake.enableKitScan: bool option?
Sometimes when giving our CMake project to new members, people often mistakenly use a scanned kit which is not configured with properties such as prefix path resulting in decreased productivity. And we are cross compiling our project to a limited number of platforms ergo unable to use the common cmake.configureArgs. It would be really convenient if this option is available.
Thank you for your feature idea. We may not be able to implement it immediately, but we will track the community reactions to determine where this might fit into our backlog. We would also accept a PR from the community if anyone would be interested in helping out!
+1, using Kits is proprietary, unnecessary and reinvents wheel. While someone may find it useful, it should not disturb people working with properly setup environment (using direnv or similar tools).
When we support CMakePresets.json, we may be able to disable this for repositories that have opted in to the new experience.
Kits were (and are) great. CMakePresets seems to provide a more standardized and configurable alternative.
This (writing our own kits/cmakepresets) is very helpful for specifying hand-crafted toolchain files.
For the moment, however, it is totally possible to select 'unspecified' and go from there without issue.
@bobbrow Thank you for your response. Sorry I wasn't able to react sooner. I'm interested in implementing this feature. Is anyone working on it currently?
No one is working on this now, so if you want to take a look at this, you are welcome to do so. One thing to note though is that if you support MSVC builds (cl.exe), the Kit scan is still currently necessary (even for Presets) so that the extension can set up the correct build environment for the Ninja generator.
I think having an exception(MSVC) in disabling kit scan would be problematic(I tend to install Build Tools in alternative directories). If loading the correct build environment is only used for generating Ninja files, having cmake point to MSVC using toolchainFile would be ideal for a user who has explicitly disabled kit scanning.
Sorry if I was unclear there. What I mean to say is that the Presets + MSVC + Ninja scenario currently has some dependencies on Kits so if a user turns of Kit scanning they might be confused as to why it is broken. I believe it was implemented that way out of convenience because the Kits are expected to be present.
There's no reason we couldn't bypass that in the extension, but if we want to have a setting that turns off Kit scanning, that code path will need to have an alternate implementation that does not take a dependency on the Kits but sets up the environment some other way. There's definitely opportunity for code reuse. I wouldn't expect you to have to start from nothing. It just might require a little bit of refactoring of stuff out of the Kits module and into something more generic. I don't think we can expect everyone to have a toolchain file handy to fill in the gap.
Thanks for the detailed info. Decoupling the setup part from Kits does seem like a good idea. I'll see what I can do.
What is the current resolution on this issue?
I have lots of projects using CMake, all handling their toolchains internally and each time I open such projects in VSCode I am annoyed by the Select a kit dialogue box, insisting for a selection that is completely useless in my use case.
Is there any way to prevent it?
If not, will a patch implementing it be accepted?
@bobbrow I wasn't able to the refactor work, but I did manage to disable the listing of scanned kits in #2520. This satisfies my use case of not being shown additional compilers that have not been configured by our project.
Thanks @bharatvaj. We will take a look. The idea seems fine to me, but we should leave this issue open to track the bigger issue around unnecessary scanning when presets are in use. We recently did some refactoring in this area, so we might already be most of the way there.
Sorry if this is a stupid question, but why does this extension insist on using kits or presets, since neither are really mandatory?
My projects use compile_commands.json for feeding IntelliSense and keep track of their build configurations in package.json (for example). The main reason for doing so is that the xPack mechanism is more generic; as seen in that example, it is neutral to the build system, and CMake, meson, proprietary, whatever, can be equally used.
Can we do something to add the options to disable scanning for kits or presets?
why does this extension insist on using kits or presets, since neither are really mandatory?
@ilg-ul because most people need them to help get their projects configured correctly. In a way, your package.json does the same basic thing as Kits and Presets; it configures the project. For folks who don't use that approach, using Kits or Presets is the way to go.
Can we do something to add the options to disable scanning for kits or presets?
That's basically what this issue is tracking.
because most people need ...
Yes, I got the point, and I have no problem for people to use them, just that neither the kits nor presets should be made mandatory, such that users who do not need them to not be permanently annoyed.
So, if there is anything I can do to help add configuration options to disable kits and presets, please let me know.
+1 The worst part is that the kits appear at an indeterminate point. So you'll be going to click on something else, and up it pops from under you, causing you to click on the wrong thing.
I would just like to never see it ever again.
Doesn't help that the bottom panel always shows up and there's often a bunch of annoying little popups at the bottom right. Can be very frustrating if you've no intention of compiling the code, don't want to make FS changes, and are just e.g. reviewing an sdk. It's starting to feel like "reject all non essential cookies" VSCode isn't really the small, sleek editor it once was.
Thanks.
I fully agree that these so called automations are very annoying and in my opinion they should not be enabled by default, neither in CMake, nor in the C/C++ extension; instead, they should require an explicit action from the user to trigger them.
But unfortunately the maintainers have a different opinion. :-(
@JonathanDotCel @frankie-zeng @cpusam thanks for your feedback. In addition to commenting, be sure to upvote (👍 react) the issue, because that's typically how we prioritize new features.
