Skip to content
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

Merged
merged 2 commits into from
May 14, 2021
Merged

Conversation

mpusz
Copy link
Contributor

@mpusz mpusz commented May 11, 2021

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).


  • I've read the guidelines for contributing.
  • I've followed the PEP8 style guides for Python code in the recipes.
  • I've used the latest Conan client version.
  • I've tried at least one configuration locally with the
    conan-center hook activated.

@conan-center-bot

This comment has been minimized.

@conan-center-bot

This comment has been minimized.

@mpusz
Copy link
Contributor Author

mpusz commented May 11, 2021

Please advise me what is the correct way to add a new version with many changes in the recipe and other files when all directory already exists?

@ericLemanissier
Copy link
Contributor

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

@mpusz
Copy link
Contributor Author

mpusz commented May 12, 2021

@ericLemanissier, just to ensure if understood correctly. After that, I will end up with

  • all that serves only for 0.6.0
  • 0.7.0 that serves for 0.7.0 and possibly next future releases
    My intent was to do the opposite one. Rename all -> 0.6.0 and add new all for the latest and future releases. However, if it is not possible I can proceed as suggested. In such a case no changes to all are needed so only one PR will suffice.

@ericLemanissier
Copy link
Contributor

You can try to do a first PR only renaming all into 0.6.0, but I'm not sure it'll be accepted by the bot. If it is, then you will be able to do a second PR to add the new versions in a folder named all without problem.

@ericLemanissier
Copy link
Contributor

Which conan version is required for this 0.7.0 recipe ?

@mpusz
Copy link
Contributor Author

mpusz commented May 12, 2021

1.33 should work just fine. This is why there is:

required_conan_version = ">=1.33.0"

tc.variables["UNITS_DOWNCAST_MODE"] = str(self.options.downcast_mode).upper()
tc.generate()
deps = CMakeDeps(self)
deps.generate()
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done :-)

@mpusz mpusz force-pushed the mp-units-0.7.0 branch from 01f81ab to ab5ddc5 Compare May 12, 2021 17:16
@conan-center-bot
Copy link
Collaborator

All green in build 3 (ab5ddc57b06c0dc72f8a69bf4c0b2366d1a3eaae):

  • mp-units/0.7.0@:
    All packages built successfully! (All logs)

compiler = self.settings.compiler
self.requires("fmt/7.1.3")
self.requires("gsl-lite/0.38.0")
if compiler == "clang" and compiler.libcxx == "libc++":
Copy link
Contributor

@madebr madebr May 12, 2021

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?

Copy link
Contributor Author

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:

https://github.com/mpusz/units/blob/43825a531fa91501277161fefd94c50a3cf0ea96/src/core/include/units/bits/external/hacks.h#L69-L214

Comment on lines +42 to +43
else:
raise ConanInvalidConfiguration("Unsupported compiler")
Copy link
Contributor

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.

Suggested change
else:
raise ConanInvalidConfiguration("Unsupported compiler")
elif compiler == 'apple-clang':
raise ConanInvalidConfiguration("apple-clang is not supported")

Copy link
Contributor

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

Copy link
Contributor Author

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"]
Copy link
Contributor

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.

Copy link
Contributor

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::?

Copy link
Contributor Author

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()

# ...

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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? 😉

Copy link
Contributor

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 😄

Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

@conan-center-bot conan-center-bot merged commit 7d3c551 into conan-io:master May 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants