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

Feature/compatible ids #5837

Merged
merged 19 commits into from Oct 29, 2019

Conversation

@memsharded
Copy link
Member

memsharded commented Sep 29, 2019

Changelog: Feature: New binary compatibility mode. Recipes can define in their package_id() an ordered list of binary package variants that would be binary compatible with the default one. These variants will be checked in order if the main package ID is not found (missing), and the first one will be installed and used.
Docs: conan-io/docs#1468

Closes #5839

This mechanism can be used:

  • To define fallback compatible binaries in case of missing ones, but use the closest or most modern one to the defined package ID.
  • To model things like the Intel compiler compatibility with other compilers (gcc, MSVC).

Maybe this feature can be tested for the Intel-Others compilers issue before releasing it.

@jgsogo

This comment has been minimized.

Copy link
Member

jgsogo commented Oct 14, 2019

A priori I think this is a nice addition, I will review it after #5836 changes are taken into account (merge develop?). At first sight, just a comment:

Would you consider an additional method?

def package_compatible_ids(self):
    for info in ...:
        self.compatible_ids.append(info)

This way, this method will only be invoked if the true-ID fails (and probably if there is an opt-in/out activated/deactivated). And probably it results in a cleaner recipe.

@memsharded

This comment has been minimized.

Copy link
Member Author

memsharded commented Oct 14, 2019

Merged develop, and yes, I think that might be a good idea, I will try it.

@memsharded memsharded marked this pull request as ready for review Oct 16, 2019
@memsharded

This comment has been minimized.

Copy link
Member Author

memsharded commented Oct 16, 2019

Status update:

  • Not using a new method, I tried it, but the logic for the new behavior remains in package_id(). Moving it later to a new method is doable, while the opposite is difficult. Also, this guarantees that the logic runs at package creation time too, so it can detect errors much earlier.
  • New syntax to add compatible configurations, please check.
  • Validation of settings and options
  • New tests covering options too, and validation errors
  • New information messages for errors and informing about compatible binaries usage.
@memsharded

This comment has been minimized.

Copy link
Member Author

memsharded commented Oct 22, 2019

@danimtb it is necessary to test this feature for a flat Intel compiler model. Please make a PoC of it.

Copy link
Member

jgsogo left a comment

I really think this feature adds a lot of value, I only have one request I've commented below.


I'm also thinking about the compatible_packages member that we could make private. It would require adding the CompatiblePackage to the conanfile in the ctor:

class CompatiblePackage(object):

    def __init__(self, conanfile):
        ...
        self._conanfile.compatible_packages.append(self)

and then we won't need the append in the package_id method:

def package_id(self):
    for optimized in range(int(self.options.optimized), 0, -1):
        compatible_pkg = CompatiblePackage(self)
        compatible_pkg.options.optimized = optimized
        # self.compatible_packages.append(compatible_pkg)

But I haven't decided yet if it is better to have or not that last line. wdyt?

@memsharded

This comment has been minimized.

Copy link
Member Author

memsharded commented Oct 23, 2019

But I haven't decided yet if it is better to have or not that last line. wdyt?

Oh, yes, I like it. I prefer that we hide the append, less lines, less interface surface. I am going to add it.

@danimtb

This comment has been minimized.

Copy link
Member

danimtb commented Oct 25, 2019

Copy link
Contributor

lasote left a comment

Do the docs

@lasote
lasote approved these changes Oct 28, 2019
Copy link
Contributor

lasote left a comment

As we discussed I don't like the interface, a user declaring a CompatiblePackage(self) is registering something magically, and the user is not accustomed to that, is accustomed to doing CMake(self) and happening nothing. But anyway, is your call.

@lasote lasote assigned memsharded and unassigned lasote and danimtb Oct 28, 2019
@memsharded memsharded requested a review from jgsogo Oct 28, 2019
@memsharded

This comment has been minimized.

Copy link
Member Author

memsharded commented Oct 28, 2019

On a second (third, fourth?) thought, I think yes it might be better to have self.compatible_packages.append(compatible_pkg) explicitly. What do you think @jgsogo, I have assigned you a review to get your final thoughts about it, you were not even sure when you suggested it.

@jgsogo

This comment has been minimized.

Copy link
Member

jgsogo commented Oct 29, 2019

I agree with the previous comments and I'd go for a more explicit approach. If there is no get-function, I think it is better to add the self.compatible_packages.append(...), otherwise it looks like there is a dangling object around and the user won't know what to do with it.

It requires documenting and exposing more interface (the compatible_packages member and the append method), but I think it will be easier for the user.

@memsharded memsharded requested a review from lasote Oct 29, 2019
@memsharded

This comment has been minimized.

Copy link
Member Author

memsharded commented Oct 29, 2019

Please check latest changes, I have added checking the final settings/options in the package_info() method, which seems to make sense.

@jgsogo
jgsogo approved these changes Oct 29, 2019
Copy link
Member

jgsogo left a comment

Great! Really needed to propagate the actual settings and options to be used by the package_info() function.

@lasote
lasote approved these changes Oct 29, 2019
@lasote lasote merged commit 5d10715 into conan-io:develop Oct 29, 2019
2 checks passed
2 checks passed
continuous-integration/jenkins/pr-head This commit looks good
Details
license/cla Contributor License Agreement is signed.
Details
@memsharded memsharded deleted the memsharded:feature/compatible_ids branch Oct 29, 2019
@memsharded memsharded referenced this pull request Oct 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.