Merge cpptools-related work into CMake Tools

[maddouri]

As discussed in https://github.com/vector-of-bool/vscode-cmake-tools/issues/155 , it would be interesting to merge the cpptools-related work into CMake Tools.

This issue is mainly for discussing the potential problems that have to be solved before doing that.

Currently, this extension:

1. Gets the list of parsed configurations from CMake Tools
2. Gets the name of the currently selected build target from CMake Tools
3. Overwrites the content of c_cpp_properties.json with the configuration of the currently selected build target. This is the only way I found so far to force cpptools to use the configuration of the current target: (source: cpptools documentation)

Problems:

1. Step 3 has the annoying effect of causing a "null" configuration to be written c_cpp_properties.jsonif no targets are found or if something like "ALL", "clean", etc. is selected... (cf. #1)
2. The current implementation, uses ServerClientCMakeTools._codeModel in order to get the per-target includes and defines. This requires cmake.experimental.useCMakeServer to be set to true. AFAIK, the non-cmake-server (i.e. "legacy") implementation of CMake Tools doesn't provide such an interface... therefore CMake Tools Helper is currently not capable of supporting projects that don't use CMake Server

[vector-of-bool]

Sorry to have vanished for a while.

I have a PR from @dcourtois that will update the c_cpp_properties.json file. I'm wondering if you could take a look at it here and tell me what you think?

I also noted that you have additional functionality such as auto-installing CMake. Would it be helpful to merge such functionality into CMake Tools as well?

[maddouri]

Hi,

Sorry for the delay. I have posted an answer at https://github.com/vector-of-bool/vscode-cmake-tools/pull/201#issuecomment-315546446

To recap, his PR does things differently, which is fine. However, for my needs, I still think of keeping my approach of "trying to take care of everything without requiring the user to configure anything"

Concerning the other features of this extension, I will try to clean the code a little bit then submit a few PRs (probably by the end of july/early august... sorry but I will be a little bit busy until then)

[dcourtois]

Hi there ! Thanks for taking the time to comment on my pull request ! Since the thread is starting to get a bit long there, I wanted to talk a bit more about cpptools related stuff here.

Basically what I would like cmake-tools to do is exactly what you listed (point 1 to 3) Now the problems lie in the problems (ahem :p) you mention:

1. This is the trickiest one. Basically there is no perfect solution, because solutions not involving the user will inevitable fail for complex project (which is my case, I'm using VSCode at work on rather big / complex projects)

2. I didn't bother with old versions of CMake (e.g. not using server mode) CMake in non-server mode is really messy to interact with. It's based on scanning things, try to second guessing others, etc. As such, I don't think it's would be wrong to just not support cpptools integration when using an old CMake version with no server mode.

Now the real problem seems to be how to handle problem 1. The way I see it, there are basically 2 approaches

1. automatically try to handle meta targets by: a. choosing the first non-meta target available (e.g. which has a list of include paths / defines / compiler flags) b. merging all the include paths / defines found on all targets. c. just warn the user that he has to select a non-meta target for the cpptools integration to work
2. let the user have full control on what to do with meta targets

The first approach might work on simple projects (ones with few targets) but in my case I'm using VSCode in a professional environment. Our project have something like 50+ targets. Most of them are libraries, but there are also many utility tools, executables that are used by other targets as preprocessing steps, etc.

You can see how the only viable option in this case is either 1.c or 2. If the cpptools integration was using 1.a or 1.b approach, it just wouldn't work: 1.a would most likely miss half the needed include paths, 1.b would add my entire hard drive as include paths :D

This is why I think the best approach is 2. This way you can have a setting that lets user choose 1 or more targets to use when a meta target is currently select. This way, what happens when he first open a CMake project is this:

1. project unconfigured, nothing works but that expected
2. he configures the project
3. the addon detects that the code model is available, and try to get the include path and defines from the currently selected target, to update the c_cpp_properties.json file a. a meta target is selected. i. the user set the default target(s), use them ii. the user didn't set the default target, notify him so that he knows why intellisense is not working b. a valid target is selected, use it

This way the user knows what's happening, and the interaction needed is kept to a minimum: either select a valid target or edit settings. And I think we can even modify step 3.a.ii to add a button which, when clicked, would open the settings.json file and automatically add the correct setting.

What do you think ?

[nick-korsakov]

@maddouri Hello and thank you for your great extension! I just want to fill my feedback as a user. I've spent a lot of time thinking why "c_cpp_properties.json" contains null configuration. Thank to debugger I've foud that cmakeToolsWrapper.defaultBuildTarget returns null. Finally I've changed all target to my real one and a miracle happens. :)

@dcourtois My opinion as a user 2-nd approach is a quite good.

But there is another little problem. After reopening VSCode selected target flips to the all again. It doesn't hard to select proper target on start but it's inconvenient. Maybe your extension may force selection of the last used target?

[dcourtois]

@nick-korsakov thanks for the input ! For the reopening problem, it's on the cmake-tools side. I didn't try to investigate why this is happening (it's probably just a matter of storing the last used target) because I'm using my patched version of cmake-tools (it's using the "2-nd approach" previously mentioned, so I'm always working on the all target, and thus do not have your problem when I re-open my workspace)

Try to go check here https://github.com/vector-of-bool/vscode-cmake-tools/issues if this issue already exists, and if not, feel free to add one.

[maddouri]

@dcourtois Ok I see. That makes sense indeed! (I mean, option 2 makes perfect sense for meta targets) As long as, when a non-meta target is selected, (case 3.b) the extension (or your PR) does everything without requiring the user to do anything, then that sounds great to me :) (btw, I've read https://github.com/vector-of-bool/vscode-cmake-tools/pull/201#issuecomment-316302962 and I do understand your PR more now. Thanks)

@nick-korsakov Thank you for providing feedback. I do share your frustration with the fact that CMake Tools selects the "all" (or another meta target) by default. Unfortunately, CMake Tools doesn't expose any API for setting the current CMake target. (AFAIK at least. @vector-of-bool I haven't read the updated code of your extension for quite some time now. So please correct me if I'm wrong) If I had access to such an API, I would:

1. Select the first non-meta target after the first configuration (resulting in a near-zero-frustration experience for the vast majority of users IMHO)
2. Keep track of the selected target between different runs of VSCode

@dcourtois as a side note / to elaborate on the motivation behind my requirements for the "cpptools integration": my typical usecases are the following:

1. Very often: opening a large number of small-to-medium-sized, (1-3 targets) unconfigured, CMake-based projects that require no special configuration (usually, cmake .. && cmake --build . are all that is needed to build them using the CLI): That is why, I want it to "just work" (exactly like in CLion) and spend precisely 0 time configuring
2. Sometimes: opening a few big/complex, (several dozens of targets/sub-projects) unconfigured, CMake-based projects that require setting some CMake cache variables. In these, relatively rare cases, in which I am destined to devout a LOT of time coding/debugging anyway, I am willing to spend time carefully configuring "stuff" ;)
3. Almost always: never keep the .vscode (or the .idea folder in the case of CLion) folder after I'm finished with the project (e.g. I don't commit .vscode to version control)

Finally, please allow me to suggest that you have a close look (if you haven't recently) at CLion. I honestly think that you might gain an interesting perspective on how a "productivity-boosting", CMake-based IDE could look like and what features/behaviors CMake Tools should have ;) (disclaimer: I regularly use multiple development environments and build systems and have no special interest in promoting any particular one except perhaps for the potential benefits that it might have on my productivity)

[dcourtois]

Hi, thanks for the CLion suggestion, but I've already tested it, and unfortunately I really don't like it (all JetBrains IDEs in fact) It's completely irrational and I can't explain why, but I really don't feel at home with it :D Maybe I spent too many years working in the video game industry (basically using Visual Studio) and I'm too old to change too much :p

Anyway, back on topic, in your use cases, case 2 is already taken care of with my "defaultTarget" approach. I understand step 3, so you need something that works out of the box by default. And here is the thing: the "defaultTarget" approach can be used to solve both step 1 and 3. Currently I'm using it like this: "cmake.defaultTargets": "target1;target2;targetWhatever". But it would be really easy to have something like: "cmake.defaultTargets": "__firstNonMeta" or even "cmake.defaultTargets": "__mergeEverything".

The names are just for clarity. With this approach, you can configure CMake Tools' behaviour in you application's settings, meaning that:

1. You can configure your VSCode to always try to look for the first valid target, unless otherwise specified in the workspace settings.
2. I can still configure my VSCode to just keep using all.

What do you think ? That would still require to add 1 global application setting, but at least, when working on all small to medium CMake projects, that would work out of the box.

[maddouri]

Different strokes for different folks, right? ;)

Indeed, having e.g. "cmake.defaultTargets": "__firstNonMeta" for people (like myself) who want "something that works out of the box by default" seems good to me. Of course, you should gather more user feedback, but I can say that I'm Ok with such an approach. :+1:

That issue being solved, how to do you plan to do point 3 of https://github.com/maddouri/vscode-cmake-tools-helper/issues/2#issue-233451332 ? (i.e. making cpptools use the same target as CMake) Last time I've checked (which was a few weeks ago) cpptools doesn't expose any API and the only way to "control" its current target (consistently) is by overwriting the content of c_cpp_properties.json and putting exactly 1 configuration. (i.e. the target's config)

[dcourtois]

I'm not sure I understand the last part (when you ask how I plan to handle point 3 of #2 comment) ? Could you elaborate on this point, with maybe one concrete example use, explaining what you think is a problem and why ?