Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initially select a target that is different from "all" #174

Closed
maddouri opened this issue Jun 10, 2017 · 7 comments
Closed

Initially select a target that is different from "all" #174

maddouri opened this issue Jun 10, 2017 · 7 comments
Labels
enhancement an enhancement to the product that is either not present or an improvement to an existing feature Feature: build stale-old to use with the close-old-issues bot
Milestone

Comments

@maddouri
Copy link
Contributor

Currently, after configuring the project for the first time or when opening an already-configured project, CMake Tools selects the "all" build target by default.

I would like to suggest that the extension selects the first target that is declared using add_executable() or add_library() instead of "all".

@maddouri maddouri changed the title Initially select a target that is different than "all" Initially select a target that is different from "all" Jun 11, 2017
@ytimenkov
Copy link
Contributor

But this is consistent with the default behavior of CMake and make: if you just run make it will build all target.
On the other hand CMake Tools select an executable as a launch target and build only it as prelaunch step.

@maddouri
Copy link
Contributor Author

maddouri commented Jun 29, 2017

Sorry for the delay.

The current behavior of the extension is indeed the same as make's.

In the case of make, (or any "build" tool) this makes perfect sense. After all, we use make to "build" a (potentially multi-sub-project) project and it's convenient if it builds all its sub-projects by default.

I would like to argue that, in the case of an "IDE" (or a code editor with IDE-like features, which VSCode is) it makes more sense to select a single target at any given time:

  1. More often than not, when "editing" a multi-target project, I edit files that are specific to one suboroject (i.e. target) which I build immediately after saving my edits
  2. For extensions (like CMake Tools Helper) that use this extension to set includes/defines in Microsoft's cpptools, (or other intellisense providers) it is not clear what to use as the current includes/defines if a "non-target" (e.g. "all") is selected. In the case of CMake Tools Helper, whent a non-target is selected, a "null" (i.e. empty, invalid...) configuration is passed to cpptools. This can be surprising to users when they load a CMake project for the first time.

Alternatively, it might be useful (at least to other extensions) if this extension provided an API for selectong the current target.

@dcourtois
Copy link
Contributor

Hi, maybe this could be selected with a simple option, something like "cmake.defaultTarget": "whatever" ? This way the default option could still be "all" to follow the default CMake behavior, and it would still be easy for users to change their default target to what they want, right ?

@ytimenkov
Copy link
Contributor

I would just remember last selected target and preserve across runs. Initially selected target doesn't really matter - it most likely will be wrong.

@maddouri
Copy link
Contributor Author

@dcourtois sure! I would suggest somerhing like "cmake.defaultTarget": "all|first_parsed_target|whatever"

@ytimenkov yes, it would be great if the selected target were preserved across runs

How about combining both ideas?

  • an option for configuring the default target during the first run
  • preserving the currently selected target across runs

@bobbrow bobbrow added the enhancement an enhancement to the product that is either not present or an improvement to an existing feature label Jul 16, 2019
@andreeis andreeis added this to the Backlog milestone May 1, 2020
@github-actions
Copy link

This issue is now marked as 'stale-old' due to there being no activity on it for the past 720 days. Unless the 'stale-old' label is removed or the issue is commented on, this will be remain open for at least 14 days and then it may be closed. If you would like to make this issue exempt from getting stale, please add the 'stale-exempt' label.

@github-actions github-actions bot added the stale-old to use with the close-old-issues bot label Oct 19, 2023
Copy link

This issue is now closed due to there being no activity on it for the past 14 days since being marked as 'stale-old'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement an enhancement to the product that is either not present or an improvement to an existing feature Feature: build stale-old to use with the close-old-issues bot
Projects
None yet
Development

No branches or pull requests

5 participants