Closed zamazan4ik closed 4 years ago
thed636
commented
4 years ago Hi, Alexander!
Nice to see your request!
I think we should wait for #256 and more critical #259. I hope to see both in master until next week. After that, we will be ready to make a 0.1.0 release. Is it ok for you?
@JonasProgrammer Jonas, would you like to continue with your PR for Conan.io package (sorry for the very long delay with this)?
zamazan4ik
commented
4 years ago Yeah, that's will be fine for me. Thank you a lot!
JonasProgrammer
commented
4 years ago @thed636 No problem regarding the delay.
As for the PR, I'd be happy to do that, however right now I'd suggest to wait a bit.
The conan guys have recently completely revamped their global package repository, but they opted to delete any config*.cmake files up there. The result is, that plenty of packages have an incompatible 'CMake interface' as of now, e.g. boost find_package(Boost) gives exactly one target Boost::Boost (note the uppercase B) and there are no separate targets per library; the linked libraries depend on conan options instead (by default, all of boost is included).
For the same underlying reasons, the conanized cmake target of ozo would be ozo::ozo instead of yandex::ozo.
Given ozo's minimum dependencies, one could use the legacy packages and conan generators, but this is not really a good option IMO, as it renders the package more or less incompatible with the central repo (which is required if the end-user wants boost >1.71, for example) and would absolutely prevent ozo's inclusion there down the road.
Luckily, there are a number of people, who are dissatisfied with the current situation and while the no-config*.cmake-policy is unlikely to go away, people are working on getting multiple properly named targets/components per package running. While this is still not as convenient as just allowing proper cmake configs -- basically all the target_compile_options_* and target_link_libraries_* stuff has to be repeated in the conan recipe -- it at least removes the blocker that is the incompatible target names.
TL;DR: Having an ozo package that works as standalone cmake, legacy conan dependencies and new-center-conan dependencies is currently impossible without ugly workarounds, but the underlying issues may be fixed in the upcoming releases.
Hi! Thank you for the such cool library! I'm interested in packaging the library into some dependecy managers. It will be much easier if you make a release on GitHub, so in a package recipe I will rely on some "stable" version instead of specific commit. E.g. it much easier to create a package for Conan with release.
Thank you!