* Use gRPC_INSTALL_LIBDIR for pkgconfig files
Fixes#25635.
If grpc libraries are installed in <prefix>/lib64, then .pc files should
be installed in <prefix>/lib64/pkgconfig. Before this commit, they were
always installed in <prefix>/lib/pkgconfig.
* Re-generate projects
* [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
* add cmake support for ccache
* cleanup: use --env-file for docker run invocations
* make python build compatible with using ccache
* enable building using ccache in selected kokoro jobs
* print ccache stats and the end of run_tests.py
* Add bundle destination for cmake install commands
Fixes the problem:
"no BUNDLE DESTINATION for MACOSX_BUNDLE" when building for iOS
* Automated change: Fix sanity tests
Co-authored-by: anton-danielsson <anton-danielsson@users.noreply.github.com>
Fix regression introduced by previous commit. Original problem that
commit was trying to fix was solved by modification of grpc recipe in
meta-openembedded project repository
Fixes#26857
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
* cmake: fix cross-compilation with gRPC_BUILD_GRPC_CPP_PLUGIN=OFF
When cross-compiling gRPC, a _native_ version of 'grpc_cpp_plugin' is
searched in the environment. For most use cases, a _cross_ version of this
file is not needed and gRPC_BUILD_GRPC_CPP_PLUGIN can be set to OFF.
However, when cross-building with -DgRPC_BUILD_GRPC_CPP_PLUGIN=OFF, there
are some build errors, for example:
make[3]: *** No rule to make target 'grpc_cpp_plugin', needed by 'gens/src/proto/grpc/reflection/v1alpha/reflection.grpc.pb.cc'. Stop.
This is because there is still a hard dependency on 'grpc_cpp_plugin' for
these targets, not taking into account the cross-compilation case.
Fix by depending on the variable gRPC_CPP_PLUGIN, which is set correctly for
either cross or native case.
* regenerate projects
* cmake: don't install plugins when crosscompiling
Plugins should not be installed for a cross-compilation environment,
because it has to run on a host/build system. If it's installed then
configure stage fails with an error, that imported target references
non-existing file. Even if the file is found, it can't be used on a host.
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
* better way of detecting protoc targets
Co-authored-by: Jan Tattermusch <jtattermusch@google.com>
* cmake: Use major.minor for the SONAME for C++ and C#
This helps to localize the ABI changes between versions and makes
possible to install different versions of GRPC side-by-side on the same
root filesystem. This is still not an ideal solution, but at least the
expectation would be whenever the core version has changed, the SONAME
would be different for any other related artifacts.
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
* doc: Add section about ABI compat to BUILDING.md
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
They use PACKAGE_VERSION to generate version information but
PACKAGE_VERSION may be overridden by find_package(). For example,
-DgRPC_CARES_PROVIDER=package with c-ares 1.16.0 overrides
PACKAGE_VERSION to 1.16.0. Because c-ares-config-version.cmake has the
following line:
set(PACKAGE_VERSION "1.16.0")
Setting PACKAGE_VERSION in version.cmake is a common CMake convention:
https://cmake.org/cmake/help/latest/command/find_package.html#version-selection
> PACKAGE_VERSION
>
> full provided version string
So we should use gRPC_CPP_VERSION not PACKAGE_VERSION to generate
gRPCConfigVersion.cmake and grpc++*.pc.
This is a CMake find-module, which attempts to find c-ares without
a CMake package file being available. If such a file is available,
it uses that. Otherwise, it searches for the library and include
directory manually.