On 31/07/20 11:03, Christian Kandeler wrote:
> There's probably no harm in adding a "fullName" property containing the
> string from the Depends item. Possibly it could even be the value of "name",
> but I'd have to take a closer look to determine what makes more sense
> semantically.
Maybe we
No, I didn't file issues in JIRA yet because there is a discussion going on
regarding a different way to handle external dependencies.
See https://codereview.qt-project.org/c/qbs/qbs/+/297830
So it's not clear to me yet if the Conan integration will be based on
ModuleProviders or on that Package
Il 31.07.2020 11:28, Jochen Ulrich ha scritto:
We also stumbled over this and a few more shortcomings of ModuleProviders when
writing a ModuleProvider to integrate the Conan package manager with Qbs.
See this thread:
https://lists.qt-project.org/pipermail/qbs/2020-February/002649.html
Interes
Hi!
> it does not look like there is any way to get the full dependency name
We also stumbled over this and a few more shortcomings of ModuleProviders when
writing a ModuleProvider to integrate the Conan package manager with Qbs.
See this thread:
https://lists.qt-project.org/pipermail/qbs/2020-
On Thu, 30 Jul 2020 23:32:11 +0300
Alberto Mardegan wrote:
>I started playing with ModuleProvider, and I find the "name" property
> a bit confusing: if the dependency was specified as
>
> Depends { name: "myprovider.a" }
>
> the the module provider in "module-providers/myprovider/prov
Adding one more question, to make sure I do not misunderstand the role
of a ModuleProvider:
Il 30.07.2020 23:32, Alberto Mardegan ha scritto:
I started playing with ModuleProvider, and I find the "name" property
a bit confusing: if the dependency was specified as
Depends { name: "mypr
Hi again!
I started playing with ModuleProvider, and I find the "name" property
a bit confusing: if the dependency was specified as
Depends { name: "myprovider.a" }
the the module provider in "module-providers/myprovider/provider.qbs"
only sees "myprovider" as "name" property -- the "a"
