Allow Bazel to build gRPC as a third-party dependency without git submodules#13060
Allow Bazel to build gRPC as a third-party dependency without git submodules#13060nicolasnoble merged 5 commits intomasterfrom unknown repository
Conversation
|
We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. |
… Bazel can build gRPC as a dependency. The WORKSPACE file now pulls third_party dependencies directly instead of requiring a git submodule init and update. The git hashes pulled by Bazel are exactly the same as the git submodules checked into third_party. A tiny bit of complexity comes from the c-ares project's use of ares_config.h.cmake and ares_build.c.cmake. The current solution to this problem is to check in a valid ares_config.h and a few valid ares_config.h files. This is the same general approach used still, but ares_config.h and ares_build.h are supplied to cares.BUILD from the only remaining local_repository, which serves only to export these two header files.
|
CLAs look good, thanks! |
|
|
So, reading more closely this PR, what I don't necessarily like about it, is the loose coupling between the actual submodules and the WORKSPACE links. I'd rather have something that makes sure that if the submodule gets updated, some sort of test indicates that the WORKSPACE file has to be updated as well. |
|
|
So to rephrase: we'd be looking for a linter that runs during run_sanity
that succeeds when the workspace matches our submodules and fails when it
does not, similar in spirit to the current check_submodules.sh script.
As an implementation hint: The WORKSPACE file is SkyLark and is
sufficiently syntactically similar to Python that we ought to be able to
read() then eval() it to verify these properties.
…On Mon, Oct 23, 2017, 2:29 PM gRPC Testing ***@***.***> wrote:
[trickle] No significant performance differences
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#13060 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJpudSTFRdhj6LN_J9yrimGX2_Yk2oNQks5svQUfgaJpZM4P-rUm>
.
|
|
Thank you for your pull request. Before we can look at your contribution, we need to ensure all contributors are covered by a Contributor License Agreement. After the following items are addressed, please respond with a new comment here, and the automated system will re-verify.
Regards, |
|
I think make it a separate script... iirc there's a json document in that
directory listing the scripts to run.
…On Tue, Oct 31, 2017, 8:06 PM The Linux Foundation ***@***.***> wrote:
Thank you for your pull request. Before we can look at your contribution,
we need to ensure all contributors are covered by a Contributor License
Agreement.
After the following items are addressed, please respond with a new comment
here, and the automated system will re-verify.
- User @jwpowell055 <https://github.com/jwpowell055> isn't covered by
a CLA. They will need to complete the form at
https://identity.linuxfoundation.org/projects/cncf
*Regards, The Linux Foundation CLA GitHub bot*
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#13060 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AJpudXcTarfqXwuyrX54FQeOnddZ77f1ks5sx-BAgaJpZM4P-rUm>
.
|
…ternal repo dependencies expressed via git submodules and those expressed as Bazel WORKSPACE rules agree exactly.
|
I've added a Python script that does impose some checks. It may require some updates if you'd like the sanity check to be performed in a slightly different way but it's a start to iterate on. Is there a formatter that was used on the other Python scripts in this directory? It's apparently not YAPF. Also, the Linux Foundation CLA requirement must've been added some I opened this PR. Is that right? |
|
ping (to prompt a reassessment of the Linux Foundation CLA) I will look at the conflict with the c-ares BUILD file tonight. |
|
I have resolved the conflict with third_party/cares/cares.BUILD. |
|
|
|
|
Your new file, grpc/tools/run_tests/sanity/check_bazel_workspace.py needs the exec bit on, I think. |
|
Thanks for the suggestion. Done. |
|
|
|
This patch adds a new tracer to support the SkyWalking tracing mechanism and format. Risk Level: Low, a new extension. Testing: Unit Docs Changes: Added Release Notes: Added Signed-off-by: wbpcode <[email protected]> Mirrored from https://github.com/envoyproxy/envoy @ 7d0f89b1011503ecd22f28e347cf7f76cba73057
8 participants
Update Bazel WORKSPACE file and third_party/cares BUILD files so that Bazel can build gRPC as a dependency.
The WORKSPACE file now pulls third_party dependencies directly instead of requiring a git submodule init and update. The git hashes pulled by Bazel are exactly the same as the git submodules checked into third_party.
A tiny bit of complexity comes from the c-ares project's use of ares_config.h.cmake and ares_build.h.cmake. The current solution to this problem is to check in a valid ares_config.h and a few valid ares_config.h files. This is the same general approach used still, but ares_config.h and ares_build.h are supplied to cares.BUILD from the only remaining local_repository, which serves only to export these two header files.