-
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
mp-units 0.7.0 support added #5517
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Please advise me what is the correct way to add a new version with many changes in the recipe and other files when |
you need to do one PR to change the files in recipes/mp-units/all, and another to add the files in recipes/mp-units/newVersion |
@ericLemanissier, just to ensure if understood correctly. After that, I will end up with
|
You can try to do a first PR only renaming |
Which conan version is required for this 0.7.0 recipe ? |
1.33 should work just fine. This is why there is: required_conan_version = ">=1.33.0" |
recipes/mp-units/all/conanfile.py
Outdated
tc.variables["UNITS_DOWNCAST_MODE"] = str(self.options.downcast_mode).upper() | ||
tc.generate() | ||
deps = CMakeDeps(self) | ||
deps.generate() |
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.
Do not use CMakeToolchain
and CMakeDeps
yet, they are not considered stable enough. Breaking changes can happen in the following Conan releases and they can break the recipe.
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.
Well, I must say I expected such an answer 😉. Now the question is should I "oldfashionize" (the opposite term to "modernize" 😉) and complicate my recipe or wait a bit until it will stabilize?
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 😄 . Waiting or oldfashionizing is up to you. Stabilizing those generators might need a couple of releases at least (Conan client) and in ConanCenter we are usually one release behind the latest one... then we can start to consider it here. It is 3 months at least.
I would prefer to oldfashionize, maybe this recipe/version is useful for some other dependency. And afterward, we can come back and modernize.
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.
Done :-)
All green in build 3 (
|
compiler = self.settings.compiler | ||
self.requires("fmt/7.1.3") | ||
self.requires("gsl-lite/0.38.0") | ||
if compiler == "clang" and compiler.libcxx == "libc++": |
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.
Isn't there a minimum versions of libc++ standard library that has ranges?
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 in llvm-12. Maybe llvm-13 will have a working implementation. Until then nasty hacks are needed:
else: | ||
raise ConanInvalidConfiguration("Unsupported compiler") |
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 typically raise for known values but leave the door open to future/unknown compilers. Here we might know it doesn't work with apple-clang
, but it might be possible to build using qnx, elbrus,... or some alias a company could be using to name their own build of gcc or clang.
else: | |
raise ConanInvalidConfiguration("Unsupported compiler") | |
elif compiler == 'apple-clang': | |
raise ConanInvalidConfiguration("apple-clang is not supported") |
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 could also copy conan-io/conan#8002
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.
Well, for now, it is hard to tell. It was only gcc-10 a few months ago, MSVC caught up at the beginning of the year, and clang joined the party only recently with clang-12 (even though I need a lot of hacks to work around its issues). I do not know of any other compiler that is supported right now. So of course, we can get rid of the else
clause here but I do not expect any other compiler to be supported in the upcoming months or even years. Well, maybe besides app-clang that probably will catch up at some point in the future. But at this time we will have 0.8.0 or more recent releases already.
compiler = self.settings.compiler | ||
|
||
# core | ||
self.cpp_info.components["core"].requires = ["gsl-lite::gsl-lite"] |
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 components can not have generic names since it produces can conflict with other package names.
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.
How is that?
Won't they get namespaced with mp-units::
?
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.
From the generatored mp-unitsTargets.cmake
:
if(NOT TARGET mp-units::core)
add_library(mp-units::core INTERFACE IMPORTED)
endif()
if(NOT TARGET mp-units::isq)
add_library(mp-units::isq INTERFACE IMPORTED)
endif()
if(NOT TARGET mp-units::si)
add_library(mp-units::si INTERFACE IMPORTED)
endif()
# ...
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 a consumer uses the pkg_config generator, then it will create core.pc
, which definitely has a high conflict potential with other recipes.
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.
Aha thanks.
So I guess it's better to pretend them with e.g. an underscore.
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.
But those are the official names used by the library. Do I really have to provide:
self.cpp_info.components["_xxx"].names["cmake_find_package"] = "xxx"
self.cpp_info.components["_xxx"].names["cmake_find_package_multi"] = "xxx"
for each and every component in the list? I personally think that sucks 😢
Also how _core
is better than core
if everyone will be forced to add _
prefix to their generic names? 😉
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.
Maybe this is something for the Conan repository: how to handle file collisions in pkgconfig world due to the usage of components because of CMake consumers.
We are not going to modify all the recipes to add those changes 😄
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.
that's probably not just a pkg-config, but any generator in general. as long as two projects define the same component such as core
, files like core.pc
or core-config.cmake
will collide, at least if we use the same directory for all dependencies.
it's probably better to isolate them in their own directories to avoid such collisions.
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.
it's probably better to isolate them in their own directories to avoid such collisions
How can I achieve that?
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.
conan does not support this (currently).
This would require adding paths to the PKG_CONFIG_PATH
environment variable.
I don't know whether the search order is documented.
Putting the generated .pc
files in different folders or overwriting them, might result in the same behavior.
Specify library name and version: mp-units/0.7.0
Well, I expect it will be an interesting review as a lot of new Conan experimental features are being used here. First of all, I found them superior to the old way to do things. Secondly, their usage makes the recipe as close as possible to the original one here https://github.com/mpusz/units/blob/master/conanfile.py which for sure will make future maintenance easier.
The old recipe had to be dropped and moved to another directory as too many changes were needed to make the new release work (there would be too many branches in a recipe to make it generic).
conan-center hook activated.