fix: remove_upb_c_rules.patch file path issue#16093
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the patch file reference in bazel/workspace0.bzl to use an explicit workspace prefix. The reviewer pointed out that using @// can lead to build failures when the repository is consumed as an external dependency and suggested using Label() to ensure the path is resolved correctly relative to the library's own workspace.
|
|
||
| # Mirrors the patch from the current bazel module | ||
| "//bazel:remove_upb_c_rules.patch", | ||
| "@//bazel:remove_upb_c_rules.patch", |
There was a problem hiding this comment.
Using @// explicitly refers to the main workspace (the root project). If this library is consumed as a dependency by another project, Bazel will look for the patch file in the consumer's repository instead of this one, which will cause the build to fail. To ensure the patch is correctly located within this repository regardless of how it is consumed, use Label() to resolve the path relative to this .bzl file. This is the standard way to handle internal references in Bazel macros that are intended for external use.
| "@//bazel:remove_upb_c_rules.patch", | |
| Label("//bazel:remove_upb_c_rules.patch"), |
11568c8 to
c448a05
Compare
|
@NeerajDwivedii Provide a description and open the PR please. |
|
@sachinpro PR ready |
This PR fixes an issue with how the
remove_upb_c_rules.patchfile path is resolved when thegoogleapisdependency is used internally by thegoogle-cloud-cppclient library.Previously,
googleapisattempted to locate the patch file in the source directory of the parent workspace that includesgoogle-cloud-cpp. This behavior is incorrect because the patch file actually belongs to thegoogle-cloud-cpprepository itself.With this fix, the patch file is now searched relative to the
google-cloud-cppdirectory, ensuring it works correctly regardless of the name or location of the parent project/workspace using the library.Current Error:
