> 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
_______________________________________________
Qbs mailing list
[email protected]
https://lists.qt-project.org/listinfo/qbs
