Description of the feature request:
Add a way for a Label to be constructed relative to the caller of a macros or the package a rule is defined in.
What underlying problem are you trying to solve with this feature?
With bzlmod enabled, rules_xcodeproj can't convert caller produced label strings (e.g. "@SwiftLint//:swiftlint") to canonical form strings (e.g. @@swiftlint~override//:swiftlint). This is because Label() called in a macro or rule uses the repo mapping from the point of view of the repo the macro or rule is defined in, instead of where the macro is called from or the target is defined in, and Label() can't be called in BUILD files to allow the caller to instantiate the label with the correct mapping. Also, rules_xcodeproj can't use an attr.label() or attr.label_list() for this use case, because these are "nodep" labels (I do not want/cannot allow these labels to cause targets to get analyzed, as they refer to targets further down the dependency tree, where they are already transitioned to another configuration).
Which operating system are you running Bazel on?
macOS
What is the output of bazel info release?
release 6.0.0
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?
No response
Have you found anything relevant by searching the web?
#17258 is related, as it shows the unknown mapping happening.
Any other information, logs, or outputs that you want to share?
No response
Description of the feature request:
Add a way for a
Labelto be constructed relative to the caller of a macros or the package a rule is defined in.What underlying problem are you trying to solve with this feature?
With bzlmod enabled, rules_xcodeproj can't convert caller produced label strings (e.g.
"@SwiftLint//:swiftlint") to canonical form strings (e.g.@@swiftlint~override//:swiftlint). This is becauseLabel()called in a macro or rule uses the repo mapping from the point of view of the repo the macro or rule is defined in, instead of where the macro is called from or the target is defined in, andLabel()can't be called inBUILDfiles to allow the caller to instantiate the label with the correct mapping. Also, rules_xcodeproj can't use anattr.label()orattr.label_list()for this use case, because these are "nodep" labels (I do not want/cannot allow these labels to cause targets to get analyzed, as they refer to targets further down the dependency tree, where they are already transitioned to another configuration).Which operating system are you running Bazel on?
macOS
What is the output of
bazel info release?release 6.0.0
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?No response
Have you found anything relevant by searching the web?
#17258 is related, as it shows the unknown mapping happening.
Any other information, logs, or outputs that you want to share?
No response