-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Multiplatform output paths are safe, correct, and efficient #6526
Copy link
Copy link
Open
Labels
P2We'll consider working on this in future. (Assignee optional)We'll consider working on this in future. (Assignee optional)not staleIssues or PRs that are inactive but not considered staleIssues or PRs that are inactive but not considered staleteam-Configurabilityplatforms, toolchains, cquery, select(), config transitionsplatforms, toolchains, cquery, select(), config transitionstype: feature request
Milestone
Metadata
Metadata
Assignees
Labels
P2We'll consider working on this in future. (Assignee optional)We'll consider working on this in future. (Assignee optional)not staleIssues or PRs that are inactive but not considered staleIssues or PRs that are inactive but not considered staleteam-Configurabilityplatforms, toolchains, cquery, select(), config transitionsplatforms, toolchains, cquery, select(), config transitionstype: feature request
Tracking issue on Bazel Configurability Roadmap
By "multiplatform" I mean any scenario where two different rules in the same build build with different settings. This also includes non-platform settings like app version, but "multiplatform" is a concise term to capture the essence.
Long-story short is
bazel-out/$(cpu)-$compilation_mode)/...doesn't work well for multiplatform builds:cpuis redundant for cpu-agnostic actions (efficiency issue: switching up the CPU shouldn't require re-executing these actions: see Java compilation doesn't include cpu in output paths #6527)This issue tracks the long and complicated effort of making a better output path syntax. Expect the next deliverable on this to be a design doc.