You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This requires a configuration transition for the target platform and the relevant build settings.
For reference, rules_go uses a transition that is applied to all target dependency attributes and the settings attribute and provides dedicated attributes on each rule to optionally configure the target and build settings on each target. This design is a workaround for Bazel imposed limitations, see bazelbuild/bazel#15157.
An alternative option is a dedicated rule that takes a separately defined Zig target in an attribute and then offers attributes to specialize the target platform or certain build settings and then applies a transition to the referenced Zig target. This has the advantage that it automatically works around bazelbuild/bazel#15157, neatly separates concerns, and is more composable. However, it has the downside that it needs to work around other Bazel imposed limitiations: A binary or test rule must specifically be defined with executable = True or test = True to be usable with bazel run or bazel test. Additionally, executable rules must produce the executable artifact themselves and cannot forward an artifact built by another rule. A common work around is to generate a symlink or a copy in the wrapper rule. But, that requires care to not break runfiles support or other relative references. It also complicates release artifacts if they need to contain both a symlink and a target.
This requires a configuration transition for the target platform and the relevant build settings.
For reference, rules_go uses a transition that is applied to all target dependency attributes and the settings attribute and provides dedicated attributes on each rule to optionally configure the target and build settings on each target. This design is a workaround for Bazel imposed limitations, see bazelbuild/bazel#15157.
An alternative option is a dedicated rule that takes a separately defined Zig target in an attribute and then offers attributes to specialize the target platform or certain build settings and then applies a transition to the referenced Zig target. This has the advantage that it automatically works around bazelbuild/bazel#15157, neatly separates concerns, and is more composable. However, it has the downside that it needs to work around other Bazel imposed limitiations: A binary or test rule must specifically be defined with
executable = True
ortest = True
to be usable withbazel run
orbazel test
. Additionally, executable rules must produce the executable artifact themselves and cannot forward an artifact built by another rule. A common work around is to generate a symlink or a copy in the wrapper rule. But, that requires care to not break runfiles support or other relative references. It also complicates release artifacts if they need to contain both a symlink and a target.The text was updated successfully, but these errors were encountered: