https://github.com/aherrmann/bazel-user-settings-example
https://github.com/aherrmann/bazel-user-settings-example
Last synced: 3 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/aherrmann/bazel-user-settings-example
- Owner: aherrmann
- Created: 2020-04-29T09:22:25.000Z (about 6 years ago)
- Default Branch: master
- Last Pushed: 2020-04-29T09:22:40.000Z (about 6 years ago)
- Last Synced: 2025-03-02T22:18:29.718Z (over 1 year ago)
- Language: Starlark
- Homepage:
- Size: 4.88 KB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
## Example of [build configurations](https://docs.bazel.build/versions/2.1.0/skylark/config.html)
This is a fork of the [original reproduction][orig_repro] of an [issue][issue]
regarding workspace prefixes on user defined configuration flags. This
reproduction has been updated to show how the situation has improved in Bazel
and where the issue remains.
[orig_repro]: https://github.com/ulysses4ever/bazel-user-settings-example/
[issue]: https://github.com/bazelbuild/bazel/issues/9177
### The minimal working setup
If you do:
```bash
bazel clean && bazel build //:my_drink
```
it will print:
```
DEBUG: .../rules.bzl:7:9: Get the default (False)
```
In contrast, if you do
```bash
bazel clean && bazel build //:my_drink --@rules_example//:favorite_flavor=True
```
it will print:
```
DEBUG: .../rules.bzl:5:9: Get the opposite of default (True)
```
I.e. the workspace name prefix is understood, so long as it is the workspace
name of an external workspace.
### The remaining bug (branch: [bug](https://github.com/ulysses4ever/bazel-user-settings-example/commit/1d79b746b0323e0450a99aedea9e8e3c3d924c07))
Change into the `rules_example` directory so that the flag becomes local.
If you do:
```bash
(cd rules_example && bazel clean && bazel build //:my_drink)
```
it will print:
```
DEBUG: .../rules.bzl:7:9: Get the default (False)
```
In contrast, if you do
```bash
(cd rules_example && bazel build //:my_drink --//:favorite_flavor=True)
```
it will print:
```
DEBUG: .../rules.bzl:5:9: Get the opposite of default (True)
```
I.e. the flag is understood so long as it's label is local.
But, if you do
```bash
(cd rules_example && bazel build //:my_drink --@rules_example//:favorite_flavor=True)
```
it will print:
```
DEBUG: .../rules.bzl:7:9: Get the default (False)
```
I.e. the flag is silently ignored, which is wrong.