Chiebot-Mirror/grpc - grpc - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Esun Kim	303e568f27	[Build] Removed gRPC_PROTOBUF_PACKAGE_TYPE, supporting config only (#32988 ) `FindProtobuf` isn't working as Protobuf began to use Abseil so gRPC is now using `CONFIG` mode for protobuf module (Context: https://gitlab.kitware.com/cmake/cmake/-/issues/24321)	2 years ago
Jan Tattermusch	0f1afec5a8	[protobuf] Upgrade third_party/protobuf to 22.x (#32606 ) The very non-trivial upgrade of third_party/protobuf to 22.x This PR strives to be as small as possible and many changes that were compatible with protobuf 21.x and didn't have to be merged atomically with the upgrade were already merged. Due to the complexity of the upgrade, this PR wasn't created automatically by a tool, but manually. Subsequent upgraded of third_party/protobuf with our OSS release script should work again once this change is merged. This is best reviewed commit-by-commit, I tried to group changes in logical areas. Notable changes: - the upgrade of third_party/protobuf submodule, the bazel protobuf dependency itself - upgrade of UPB dependency to 22.x (in the past, we used to always upgrade upb to "main", but upb now has release branch as well). UPB needs to be upgraded atomically with protobuf since there's a de-facto circular dependency (new protobuf depends on new upb, which depends on new protobuf for codegen). - some protobuf and upb bazel rules are now aliases, so ` extract_metadata_from_bazel_xml.py` and `gen_upb_api_from_bazel_xml.py` had to be modified to be able to follow aliases and reach the actual aliased targets. - some protobuf public headers were renamed, so especially `src/compiler` needed to be updated to use the new headers. - protobuf and upb now both depend on utf8_range project, so since we bundle upb with grpc in some languages, we now have to bundle utf8_range as well (hence changes in build for python, PHP, objC, cmake etc). - protoc now depends on absl and utf8_range (previously protobuf had absl dependency, but not for the codegen part), so python's make_grpcio_tools.py required partial rewrite to be able to handle those dependencies in the grpcio_tools build. - many updates and fixes required for C++ distribtests (currently they all pass, but we'll probably need to follow up, make protobuf's and grpc's handling of dependencies more aligned and revisit the distribtests) - bunch of other changes mostly due to overhaul of protobuf's and upb's internal build layout. TODOs: - [DONE] make sure IWYU and clang_tidy_code pass - create a list of followups (e.g. work to reenable the few tests I had to disable and to remove workaround I had to use) - [DONE in cl/523706129] figure out problem(s) with internal import --------- Co-authored-by: Craig Tiller <ctiller@google.com>	2 years ago
Jan Tattermusch	43c3d1f932	Switch all VS2017 builds to VS2019 (#32662 ) (part of removing support for VS2017) Also see https://github.com/grpc/grpc/pull/32649 Also see https://github.com/grpc/grpc/pull/32615 The switch to grpc-win2019 windows workers has already happened: (cl/517400022). Once this PR lands, I'll backport to 1.53.x branch as well (since that release removes the VS2017 support).	2 years ago
Jan Tattermusch	3fde13929b	Switch to protobuf's /CMakeLists.txt instead of /cmake/CMakeLists.txt (#32678 ) Try to react to https://github.com/protocolbuffers/protobuf/issues/12263 and https://github.com/protocolbuffers/protobuf/pull/12295 Protobuf's /cmake/CMakeLists.txt is now deprecated if favor of /CMakeLists.txt `58ecf38aa5/cmake/CMakeLists.txt (L3)` In this PR: - Adjust `cmake/protobuf.cmake` to use the right CMakeLists.txt - adjust the C++ distribtests accordingly	2 years ago
Jan Tattermusch	5873ba96dc	Ensure compatibility with the new custom kokoro win2019 image (#32649 ) Fix incompatibilities identified when running adhoc runs on the new custom win2019 image. After merging this, it should be possible to switch to the new image without breaking any tests. - for most fixes I added a comment that explains why they're necessary. - the new image won't have VS2015 installed, so I'm switching the protoc artifact build to VS2017 This PR will need to be backported to older release branches to ensure the windows tests continue working on those branches as well (IMHO I haven't made any changes that would be difficult to backport and I tried to keeps the diff as small as possible to avoid issues when backporting). After we switch to the new image (and all the windows tests are green), we can incrementally move the builds that are still using VS2017 to VS2019.	2 years ago
Lidi Zheng	99752b173c	[xDS Proto] Enhence gRPC buildgen for 3rd party proto compilation (#29254 ) * [xDS Proto] Enhence gRPC buildgen for 3rd party proto compilation * Rebase from master to update envoy-api version * Address reviewer's comments * Address reviewer's comment * Regenerate project * Rename external_library * Address reviewer's comments * Add comments for the internals of generate C++ proto code * Add proto file as a dependency to the custom command	3 years ago
Jan Tattermusch	7924a5fde7	add task_runner.py --inner_jobs support for C++ distribtests (#28594 ) * add support for task_runner.py --inner_jobs for C++ distribtests * fine tune linux c++ distribtests parallelism * yapf code	3 years ago
Esun Kim	192928c997	Use gRPC_BUILD_MSVC_MP_COUNT for windows cmake distrib tests (#28202 )	3 years ago
Donna Dionne	8dd0cb4712	Add support for xDS regex matchers.	4 years ago
Esun Kim	5207eba9ff	Add abseil	5 years ago
Esun Kim	f43cb1a2a1	Update by review	5 years ago
Esun Kim	aeb19f5d50	Clean up scripts for cmake tests	5 years ago
Jan Tattermusch	d4c1c9b18c	try fixing protobuf build in win distribtest	6 years ago
Jan Tattermusch	5e9cfd9a99	cleanup the way openssl and zlib are used	7 years ago
Stefan Hacker	93f13871d8	Fix helloworld zlib include directory confusion in run_distrib_test_cmake.bat We have to give cmake the explicit zlib location as the internal testing environment has C:/msys64/usr/bin in the PATH and zlib-devel installed. cmake has heuristics in find_package which sees this /bin suffix in PATH and adds C:/msys64/usr/ to the find_package search locations. Doing a find_package(zlib) in this environment makes the find module for it (FindZLIB) find the header zlib.h in C:/msys64/usr/include while the library will still be taken from the testinstall location masking the issue in the log. To satisfy the dependency cmake adds C:/msys64/usr/include as an include directory. This makes cl.exe build with mixed C and C++ standard lib headers breaking the build. This issue was previously masked by cmake writing absolute paths for zlib and other dependencies into the grpc cmake exports.	7 years ago
Jan Tattermusch	1e9543deb9	fix finding openssl	7 years ago
Jan Tattermusch	1c42023ae6	fix distribtest typo	7 years ago
Jan Tattermusch	a5f05c70f1	avoid picking up ProtoC	7 years ago
Jan Tattermusch	27d254ad78	installing gflags not necessary	7 years ago
Jan Tattermusch	ce7a23ba94	make runnable on kokoro	7 years ago
Jan Tattermusch	06251f8cd6	make helloworld CMakeLists compile on windows	7 years ago
Jan Tattermusch	3c93a1982d	working cmake install on windows	7 years ago

22 Commits (a35f282d58a927177a28b68a0b28d5979f05f3e2)