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.
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
[utf8.h] Add library and packages #4858
[utf8.h] Add library and packages #4858
Changes from 1 commit
a1e4120
a2723df
c614283
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Is this needed? I believe it was added for components names or similar
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.
I think it's more or less informational only. CCI policy is to require latest client anyway.
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.
Indeed, it can be removed.
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.
Not needed, sorry. It was a leftover (copy/paste) from another recipe with
validate
method.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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have a dot in
approvaltests.cpp
package andutf8.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.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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If some generators like
cmake
andcmake_find_package[_multi]
get deprecated in the future in favor ofCMakeDeps
(conan-io/conan#8568) and the CMakeToolchain, we need recipes to be prepared for that migration: the targets will be available inCMakeDeps
, but${CONAN_LIBS}
won't...