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

Add bazel.info.* commands #273

Closed
jfirebaugh opened this issue Aug 18, 2022 · 1 comment
Closed

Add bazel.info.* commands #273

jfirebaugh opened this issue Aug 18, 2022 · 1 comment

Comments

@jfirebaugh
Copy link
Collaborator

I propose adding a set of commands to the plugin: bazel.info.bazel-bin, bazel.info.bazel-genfiles, and so on, for all or some subset of the bazel info keys. Each command would do nothing but output the value of the corresponding key.

Here's why this would be useful: command variables. Using these commands, one could define launch configurations in a way that does not hard-code architecture-specific or workspace-specific details. For example instead of writing

  "program": "${workspaceFolder}/bazel-out/darwin-dbg/bin/example",

as in this widely-cited post, you could write:

  "program": "${command:bazel.info.bazel-bin}/example",

The latter will work on Apple Silicon and workspaces that use --experimental_convenience_symlinks=clean.

If there's support for this feature, I can supply a PR.

jfirebaugh added a commit to figma/vscode-bazel that referenced this issue Aug 31, 2022
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 bazel-contrib#273 and could form the basis of bazel-contrib#217, bazel-contrib#207, and bazel-contrib#115.
@jfirebaugh
Copy link
Collaborator Author

The bazel.info.* approach to launch configurations turns out not to generalize widely enough, but I think this will: #275.

jfirebaugh added a commit to figma/vscode-bazel that referenced this issue Sep 9, 2022
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 bazel-contrib#273 and could form the basis of bazel-contrib#217, bazel-contrib#207, and bazel-contrib#115.
coeuvre pushed a commit that referenced this issue Sep 12, 2022
* Add bazel.getTargetOutputs command

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 #273 and could form the basis of #217, #207, and #115.

* Add/update docs

* Lint
jfirebaugh added a commit that referenced this issue Dec 14, 2022
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}",
      ]
```
vogelsgesang added a commit to vogelsgesang/vscode-bazel that referenced this issue Feb 27, 2024
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  bazel-contrib#273, bazel-contrib#275 and bazel-contrib#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.
vogelsgesang added a commit to vogelsgesang/vscode-bazel that referenced this issue Feb 27, 2024
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  bazel-contrib#273, bazel-contrib#275 and bazel-contrib#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.
cameron-martin pushed a commit that referenced this issue Feb 28, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant