(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).
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.
* [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
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.
Jan Tattermusch
Lidi Zheng
Jan Tattermusch
Esun Kim
Donna Dionne
Stefan Hacker