[utf8.h] Add library and packages #4858
Conversation
This comment has been minimized.
This comment has been minimized.
|
All green in build 2 (
|
recipes/utf8.h/all/conanfile.py
Outdated
| import re | ||
| from conans import ConanFile, tools | ||
|
|
||
| required_conan_version = ">=1.28.0" |
There was a problem hiding this comment.
Is this needed? I believe it was added for components names or similar
There was a problem hiding this comment.
I think it's more or less informational only. CCI policy is to require latest client anyway.
There was a problem hiding this comment.
Not needed, sorry. It was a leftover (copy/paste) from another recipe with validate method.
|
All green in build 3 (
|
| find_package(utf8.h REQUIRED CONFIG) | ||
|
|
||
| add_executable(${PROJECT_NAME} test_package.cpp) | ||
| target_link_libraries(${PROJECT_NAME} utf8.h::utf8.h) |
There was a problem hiding this comment.
As you wish, but I would not recommend to show non-official CMake config files or imported targets in test_package.
There was a problem hiding this comment.
I see, here we have a problem. We want to push existing packages and consumers to start using targets (right now, moving to cmake_find_package[_multi] generator), what to do with these libraries that don't have official or unofficial targets?
I would really like to know what you think cc/ @uilianries @SSE4 , maybe we are wrong trying to force using targets and/or config files?
There was a problem hiding this comment.
I see. It's fine for me, I just try to use cmake_find_package[_multi] in test_package when we properly mimic an official find or config module file, but there is no "rule".
In fact, a usage file in each recipe would be nice, to properly document if a given recipe provides transparent integration through cmake_find_package, cmake_find_package_multi or pkg_config generator, how to call find_package, which components are defined, and which imported targets etc.
Because it's might not be obvious for consumers if a recipe properly emulates official config files or not (several recipes have very complex and non-intuitive package_info()). But that's a different topic.
There was a problem hiding this comment.
You can run conan install xxxx --generator markdown and it will show some information, among that information it is how to consume the library using common generators.
There was a problem hiding this comment.
I know, but it doesn't say if this is a proper emulation of official CMake config or module files. Looking at this markdown, consumer can't really know if he can rely on these informations for transparent integration or not. He still have to lost time to dig into original project (which is not always obvious if there is a lack of documention) to figure out if we properly emulate those informations or not.
There was a problem hiding this comment.
Understood, but the only alternative would be to read the actual source from test_package/CMakeLists.txt with its comments (assuming we are commenting if the integration is using official targets or not).. and that's not possible.
There was a problem hiding this comment.
Typically for these cases we just opt for the ${CONAN_LIBS}
there's nothing in the recipe adding something special to the cmake find generators ... why test the Conan implementation here? I think it's easier to test the recipe rather than how it might be consumed.
There was a problem hiding this comment.
the projects which don't originate from the CMake (e.g. use another build system) usually don't have official module/target names. still, CMake documentation states that these projects could be imported to the CMake:
https://cmake.org/cmake/help/v3.20/manual/cmake-developer.7.html#find-modules
https://cmake.org/cmake/help/v3.20/manual/cmake-packages.7.html#creating-packages
so, if foreign projects follow the sane CMake naming conventions, they could still be used in CMake, even without an official target.
as soon as official target added later, conan package could be updated to provide an alias with build modules.
There was a problem hiding this comment.
If some generators like cmake and cmake_find_package[_multi] get deprecated in the future in favor of CMakeDeps (conan-io/conan#8568) and the CMakeToolchain, we need recipes to be prepared for that migration: the targets will be available in CMakeDeps, but ${CONAN_LIBS} won't...
Co-authored-by: SpaceIm <30052553+SpaceIm@users.noreply.github.com>
|
All green in build 4 (
|
|
|
||
|
|
||
| class Utf8HConan(ConanFile): | ||
| name = "utf8.h" |
There was a problem hiding this comment.
is the . acceptable for the naming convention?
Is this too generic? https://github.com/search?l=C%2B%2B&p=2&q=utf8&type=Repositories
There was a problem hiding this comment.
I don't see valid reason why dot shouldn't be allowed in the reference. I'd actually allow any characters, maybe except / and @ which are used as separators.
There was a problem hiding this comment.
We already have a dot in approvaltests.cpp package and utf8.h is the name of the library. I also feel a bit strange, but IMHO it is a valid character for a reference and it's been the authors' choice, I think it is better to use it than to rename the library.
Specify library name and version: lib/1.0
conan-center hook activated.