-
Notifications
You must be signed in to change notification settings - Fork 74
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
Add bazel.getTargetOutput command #275
Conversation
additionalOptions: string[] = [], | ||
sortByRuleName: boolean = false, | ||
query: string, | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update @param additionalOptions
in the method doc to reflect the change of parameter type.
@@ -88,12 +77,8 @@ export class BazelQuery extends BazelCommand { | |||
* @returns An sorted array of package paths containing the targets that | |||
* match. | |||
*/ | |||
public async queryPackages( | |||
additionalOptions: string[] = [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
@@ -116,7 +101,10 @@ export class BazelQuery extends BazelCommand { | |||
* @returns A promise that is resolved with the contents of the process's | |||
* standard output, or rejected if the command fails. | |||
*/ | |||
private run(additionalOptions: string[] = []): Promise<Buffer> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
import { BazelCommand } from "./bazel_command"; | ||
|
||
export class BazelInfo extends BazelCommand { | ||
public async run(key: string): Promise<string> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add method-level doc for public method.
|
||
import { BazelCommand } from "./bazel_command"; | ||
|
||
export class BazelInfo extends BazelCommand { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add class-level doc for public class.
|
||
import { BazelQuery } from "./bazel_query"; | ||
|
||
export class BazelCQuery extends BazelQuery { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add class-level doc for public class.
import { BazelQuery } from "./bazel_query"; | ||
|
||
export class BazelCQuery extends BazelQuery { | ||
public async queryOutputs( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add method-level doc for public method.
This command can be used in launch configurations to obtain the path to an executable built by Bazel. For example, you can set the "program" attribute of a launch configuration to an input variable: "program": "${input:binaryOutputLocation}" Then define a command input variable: "inputs" [ { "id": "binaryOutputLocation", "type": "command", "command": "bazel.getOutputTarget", "args": ["//my/binary:target"], } ] Addresses bazelbuild#273 and could form the basis of bazelbuild#217, bazelbuild#207, and bazelbuild#115.
4a3cede
to
b5aec72
Compare
👍🏻 Done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I missed testing this case with command input variables in #275. IMO it's a VSCode bug that the calling convention is different than with `vscode.commands.executeCommand` (microsoft/vscode#167970), but nevertheless we need to handle it.
I proposed these originally in #273 as an initial idea for what became #275. But I have encountered another use case that makes me think they are generally useful: When [debugging on macOS](bazelbuild/bazel#6327 (comment)), lldb needs to be configured with the command `platform settings -w $execution_root`, where `$execution_root` is what's returned by `bazel info execution_root`. With `bazel.info.*` commands, you can create a launch configuration that contains: ``` "initCommands": [ "platform settings -w ${command:bazel.info.execution_root}", ] ```
The commands `bazel.info.*` and `bazel.getOutputPath` are intended to be used by the command variables within `launch.json` and `task.json`. For additional context, see bazelbuild#273, bazelbuild#275 and bazelbuild#291. Those commands are not intended to be called by users directly. As such, they should not show up in the command picker. This commit removes them from the `commands` contribution point, thereby hiding them from the command picker.
The commands `bazel.info.*` and `bazel.getOutputPath` are intended to be used as command variables within `launch.json` and `task.json`. For additional context, see bazelbuild#273, bazelbuild#275 and bazelbuild#291. Those commands are not intended to be called by users directly. As such, they should not show up in the command palette. Calling them from the command picker has no user-visible effect and leaves the user with the impression that those commands would be broken. This commit removes them from the `commands` contribution point, thereby hiding them from the command picker. To make sure that the extension is loaded as soon as some `task.json`/`launch.json` invokes any of those commands, they now need to be registered as `activationEvents`, since VS Code will no longer discover those events automatically from the `commands` contributions.
The commands `bazel.info.*` and `bazel.getOutputPath` are intended to be used as command variables within `launch.json` and `task.json`. For additional context, see #273, #275 and #291. Those commands are not intended to be called by users directly. As such, they should not show up in the command palette. Calling them from the command picker has no user-visible effect and leaves the user with the impression that those commands would be broken. This commit removes them from the `commands` contribution point, thereby hiding them from the command picker. To make sure that the extension is loaded as soon as some `task.json`/`launch.json` invokes any of those commands, they now need to be registered as `activationEvents`, since VS Code will no longer discover those events automatically from the `commands` contributions.
This command can be used in launch configurations to obtain the path to an executable built by Bazel. For example, you can set the "program" attribute of a launch configuration to an input variable:
Then define a command input variable:
Addresses #273 and could form the basis of #217, #207, and #115.