Skip to content

aherrmann/bazel-user-settings-example

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

9 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

This is a fork of the original reproduction of an 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.

The minimal working setup

If you do:

bazel clean && bazel build //:my_drink

it will print:

DEBUG: .../rules.bzl:7:9: Get the default (False)

In contrast, if you do

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)

Change into the rules_example directory so that the flag becomes local.

If you do:

(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

(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

(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.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published