* cmake: add separate export for plugin targets
Add a separate CMake export for the plugin targets to separate binaries
and libraries into their own CMake target export files. Skip the cross
compiled binary plugin targets during cross compile because they are not
usable and not always available.
The Yocto build system doesn't install cross compiled binaries into the
target sysroot. This makes the CMake gRPC config useless as it checks
the existent of binaries and fails without the binaries.
This is a strip down version of #22498 and related to #26148 and #26857.
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
* regenerate cmake file
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Co-authored-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
* 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.
Esun Kim
Clément Péron
Valentin
Craig Tiller
Andres Beltran
Michael Nosthoff
Ben Beasley
hongnod
Jérôme Duval
Lidi Zheng
Jan Tattermusch
Anton Danielsson
hexchain
Vyacheslav Yurkov
Pablo Busse
Thomas De Schampheleire
Timo Lange
Anatol Belski
donnadionne
capstan
Paul Wankadia
Jan Tattermusch
Adrian Imboden
Uwe Kindler
Sutou Kouhei
Kyle Edwards