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

Support build mode, target platform, libc, etc. selection per build target #39

Open
3 tasks done
Tracked by #1
aherrmann opened this issue Feb 26, 2023 · 0 comments
Open
3 tasks done
Tracked by #1

Comments

@aherrmann
Copy link
Owner

aherrmann commented Feb 26, 2023

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.

@aherrmann aherrmann mentioned this issue Feb 26, 2023
63 tasks
@aherrmann aherrmann added this to the version 0.1 milestone Feb 26, 2023
@aherrmann aherrmann removed this from the version 0.1 milestone Dec 1, 2023
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