[Qbs] Interfacing Qbs to Conan

[Jochen Ulrich]

>  It would be great if Qbs 1.16 could offer a complete Conan story. We have roughly a month until feature freeze.

The ticket(s) I will create are not a requirement for the Conan ModuleProvider we implemented. So we should not have a problem with this deadline.
The things from the ticket(s) would just allow a simpler/better implementation of the ModuleProvider and improve its usability.


> It might be beneficial if module providers [...]

Yeah. Those three things would really be helpful.


> I do not think they should have direct access to probes/properties defined in the project/product by the user because this would be an "invisible" dependency. That means: A provider should not rely on project.mycustomProperty.

Okay. That's true. And if the other three things would be possible, it would be unnecessary to have access to the probes/properties defined in the project/product.


> Are you aware that module providers operate on product level? You can (currently) configure them in the profile and in the product.

Yeah but that's not correct for the Conan ModuleProvider and probably also for other ModuleProviders. What they need are properties on *project* level.
They should not be configured in a profile because they are specific to a project. And you don't want to repeat them for every product in the project.


> We could also add the capability to "configure" the fallback provider via the Depends item [...]

I also thought about this. However, I would call the property simply "providers" instead of "fallbackProviders":
    
    Depends {
        name: "mylib"
        providers: [
            "conan",
            "pkgConfig"
        ]
    }


>    https://codereview.qt-project.org/c/qbs/qbs/+/288927 achieves automatic probe re-execution by assigning the modification time stamp of the conanfile to a property of the probe.

Yeah. Something like this. Except for ModuleProviders.


>    An --force-module-generator-execution command line flag might be worth to add to qbs resolve.

I would call it --force-module-provider-execution to make it clear that its related to the ModuleProviders.


So to summarize: we have the following new requirements regarding ModuleProviders:

1. ModuleProviders should be able to define their own probes.
2. ModuleProviders should be able to define a logic to "invalidate" their generated modules (force regeneration of the modules).
3. ModuleProviders should be able to access the project and product they live in.
4. Projects should be able to configure ModuleProviders like it is possible in products.
5. Depends items should be able to define which ModuleProviders to use. Doing this invokes the ModuleProvider like a fallback ModuleProvider (meaning it gets the complete "name" of the Depends item).
6. qbs resolve should provide a command line flag --force-module-provider-execution to force regeneration of modules by ModuleProviders.

Should I create one or multiple tickets for these requirements?
To me it sounds like 1, 3 and 4 might be related while the others are rather independent.

Best
Jochen