Independent/Dependent options for more flexible build resolution

I don’t believe the provided methods of build_id and package_id can be used for the following use case. If they do, please advise how. Thanks!

Assume I have a package that can optionally include add-on modules A and B. Options to include A and/or B are completely independent of each other.

options = {
    "a": [True, False],
    "b": [True, False]
}

default_options = "a=False", "b=False",

This leaves me 4 combinations of options. If I run conan install -o a=True, it must pick options corresponding to a=True and b=False.

It would be convenient if I could specify in my recipe that options a and b are independent of one another. That way when I run conan install -o a=True, the value for option b is a don’t-care. I can now resolve to 2 of the 4 possible combinations.

Of course this is a trivial example. What if the recipe has 6 independent options? That’s 64 options combinations. If I could mark them as independent, there would be a far greater chance I could find an available binary and not have to build. For example, if I care about 1 option and the rest are don’t-cares, than 32 of the 64 combinations would satisfy the request.

Consider a Qt recipe that has over a dozen options, many of them independent. Qt is especially painful to fetch and build. I hate having to start over because I decided to enable/disable a single option. I want to increase the odds that a option combination I’ve already built can be used. I could even do an initial build with all the add-ons enabled and then most of the combinations would resolve to that superset.

[lasote]

You could use two approaches:

1. Use the configure method to control the activated options. In the following example, it’s controlled that only one option is activated and any other is removed from the options.

    def configure(self):
        activated = [(opt, value) for opt, value in self.options.values.as_list() if value]
        if len(activated) > 1:
            raise Exception("Only one option can be activated: %s" % activated)
        for name, value in self.options.values.as_list():
            if not value:
                self.options.remove(name)

1. Use an open value option to specify the module to be activated:

class MyPkg(ConanFile):
    ...
    options = {"shared": [True, False], "modules": "ANY"}

You could give any value to “modules” and use the configure() method to limit the possible values/control invalid values.

[memsharded]

I would say that the way to tell the users that you don’t care about some option of your dependencies, is simply not doing anything. This is the default.

What you can do, is to manage the options that you do care:

• Define some defaults for your dependencies. If nobody else defines those options, they will be the ones that will be used
• Raise for incompatible options. You can try to check values in the configure() method, and raise an Exception accordingly, if your library is incompatible with the options that are being provided from downstream.