-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
protobuf: restore 3.17.1 + improve robustness of test_v1_package conanfile.py #15518
protobuf: restore 3.17.1 + improve robustness of test_v1_package conanfile.py #15518
Conversation
I detected other pull requests that are modifying protobuf/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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hooks produced the following warnings for commit b0b9a7fprotobuf/3.19.6
protobuf/3.21.9
protobuf/3.17.1
protobuf/3.19.4
|
Is there an OpenCV issue or documentation that specifies the upper bound for the protobuf version? |
No, but in #15193 I've tried to bump protobuf and build failed with any version greater than 3.17.1 In OpenCV, they allow to build a vendored protobuf. It was 3.5.2 for a long time, and has been updated to 3.19.1 in OpenCV 4.5.5 but with some patches to keep compatibility I think: opencv/opencv#20998. It has not been backported to OpenCV 3.x branch anyway. |
On which platform/compiler were the issues experienced? I can't locally reproduce this - I'm able to build OpenCV 4.x with the most recent protobuf. |
MacOS, all shared. |
Thanks! I'm still unable to reproduce the issue on macOS. I'm building OpenCV 4.5.5 against Protobuf 3.21.4 with everything The vendored-in version of protobuf in OpenCV needs to be anchored to the exact same version as the vendored-in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
waiting for feedback related to issues with versions newer than 3.17.1 -
I've tried again because I've tested 2 or 3 weeks ago. Indeed it works fine in 4.5.5, but it fails in OpenCV 4.5.0 if protobuf is greater than 3.17.1 (and I guess for all OpenCV before 4.5.5):
Anyway, I think it's a bad idea to drop maintenance of versions in PR doing conan v2 migrations unless there is a good reason, because these recipes will be totally broken soon, not just unmaintained. |
Thanks! Let me investigate |
This has been fixed upstream - this has also been backported to 3.x releases as well. Given that this looks like a trivial patch (and also considering that they appear to have been using a very old deprecated function signature) - I would advise to fix this in the OpenCV recipe and bump the version rather than continue to maintain 3.17.1. I'm happy to do this unless there's already a PR open where this can be done. I agree versions shouldn't be dropped that are still in use. The 3.17.1 recipe is still there and available and working in the configurations it was tested when it was last published - so I dont think users are experiencing any issues. Given how easy it seems to fix OpenCV, the sooner we fix that, the less need to re-add an old version. |
I can incorporate this patch in #15193
It's still there but not migrated to conan v2. Given backward & forward compatibility issues in profile against conan v1 & v2 recipes, and that conan v2 won't support legacy helpers, I don't think it's a good thing, and it will be worse once conan v2 released. |
This comment has been minimized.
This comment has been minimized.
Conan v1 pipeline ✔️All green in build 6 (
Conan v2 pipeline (informative, not required for merge) ✔️
All green in build 6 (
|
@jcar87 still any reason to block this PR given that protobuf 3.18 has removed deprecated functions, and 3.17.1 will not be usable in conan v2 client without this PR? I don't ask to maintain this version forever, just to have at least one RREV of this version with full conan v2 support. |
We currently don't offer hard guarantees that the recipes or packages work with Conan 2.0, so older versions of OpenCV not building with Conan 2.0 today due to a revision of Protobuf 3.17.1 not existing for Conan 2.0, can also easily be solved by applying the upstream patch from OpenCV. I appreciate the intention, but neither OpenCV nor Protobuf were Conan 2.0 compatible until very recently, so I don't consider this a regression. I believe that if the goal is to enable all versions of the OpenCV recipe to build with Conan 2.0, the version of the Protobuf dependency should be bumped, along with applying the upstream patch. I see no point in going backwards when the CI efforts of the alternative are roughly equivalent. I have, however, dismissed my review as the issue has been clarified. |
…t_v1_package conanfile.py * robust conanfile for test_v1_package * restore 3.17.1 * use correct 3.21.9 url * fix patch fields * fix removal of libprotobuf-lite * add libm to system libs * cleanup
restore 3.17.1: Address review in protobuf: Update to new CMake integrations #14851 (comment). Maintenance of this version has been removed during conan v2 migration, but it's still widely used in other CCI recipes (like OpenCV), which can't depend on newer versions than this one, therefore it's not a good thing to not have migrated this version to conan v2 helpers nor to drop its maintenance.
test_v1_pacage: Inspired from test_v1_package conanfile of capnproto. I've experimented a lot both 1 & 2 profiles while migrating capnproto.
The idea is to avoid a patch in Add protobuf 3.5.1.1 version #15202 due to this error in test v1 package: Add protobuf 3.5.1.1 version #15202 (comment), which comes from a lack of robustness in test v1 package.