grpc: fix cross-build + provide all CMake executable imported targets + add shared option + modernize #9044
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
mentioned this pull request
|
I detected other pull requests that are modifying grpc/all recipe: This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there. |
SpaceIm
force-pushed
the
grpc-modernize
branch
from
9dac50a
to
6244627
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
link of targets was broken. It was working only due to global injection of many stuff through conan_basic_setup()
SpaceIm
force-pushed
the
grpc-modernize
branch
from
d0b2f78
to
000c2f0
Compare
|
My gosh, I've realized something while trying to support shared in grpc recipe: When you call the install target, CMake doesn't only copy files, it removes rpath by default in installed libraries, so Basically Hoping it's not the default in conan v2. /cc @memsharded @lasote |
|
Basically here is neat behavior for conan-center (grpc shared generated with
grpc_cpp_plugin in the build treegrpc_cpp_plugin in the install treeYou see that:
|
SpaceIm
force-pushed
the
grpc-modernize
branch
from
ba7b87c
to
7adc97c
Compare
This comment has been minimized.
This comment has been minimized.
this a limitation of current conan model. Could be enabled again with CMakeToolchain + VirtualBuildEnv.
This comment has been minimized.
This comment has been minimized.
SpaceIm
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
seriously? Ok, so it turns out that abseil uses non-namespace nan. It means that they may not use nan from libstdc++, therefore requiring to link libm in abseil recipe: https://github.com/abseil/abseil-cpp/blob/fbbb5865a562c9a9167d71c1cf56b82025a8f065/absl/strings/charconv.cc#L86-L91 I'll fix it in #6383 |
|
@SpaceIm In develop2 there is no |
4 tasks
This comment has been minimized.
This comment has been minimized.
|
? |
|
Not really sure to understand why CI tried to build again. |
This comment has been minimized.
This comment has been minimized.
SpaceIm
dismissed stale reviews from uilianries and prince-chrismc
via
065d579
prince-chrismc
approved these changes
Feb 10, 2022
This comment has been minimized.
This comment has been minimized.
|
All green in build 33 (
|
SSE4
approved these changes
Feb 21, 2022
SSE4
pushed a commit
to madebr/conan-center-index
that referenced
this pull request
Feb 21, 2022
…imported targets + add shared option + modernize * modernize * provide all CMake executables targets * fix cross-build & patch in build() instead of source() * fix test package link of targets was broken. It was working only due to global injection of many stuff through conan_basic_setup() * simplify test package * add shared option * do not test shared if cross-building this a limitation of current conan model. Could be enabled again with CMakeToolchain + VirtualBuildEnv. * fix cross-build to iOS * handle codegen option in package_info() * secure option doesn't affect package_id this option doesn't exist upstream. It's a hack to hide unsecure components in global target generated by conan. * drop shared with libstdc++/libstdc++11 for the moment * test package: help gprc_cpp_plugin to find grpc_plugin_support if shared at build time * handle cross-build in test package * typo * gRPC shared buils fine with clang on Linux * fix install of plugins if cross-building this bug exists in all versions of the range [1.39.0;1.42.0[ * with gcc allow grpc shared if abseil shared it allows folks to create grpc shared, but we should find a way to compile with gcc grpc shared against abseil static * really use @relative_path@
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a big PR fixing several issues:
gRPC::<plugin>executable targets, not onlygRPC::grpc_cpp_plugin. I've turned the custom module file to a template file reused at package time to generate one file per executable.protobuf::protoctarget coming from conan generators. When this recipe will useCMakeToolchain, the patch could be removed thanks to CMakeToolchain: proper support of find_*() & include() commands conan#10186, because find_program() will always find executables from build context first.conan_basic_setup(TARGETS), it would have never passed CI withCMakeToolchain) and using custom logic, not standard module file from protobuf => now the CMakeLists of test package shows a proper usage of protobuf + grpc.closes #6382
closes #8560
conan-center hook activated.