Qbs has a global view of the entire project, so there's no need to qualify the
names of your lib1, lib2 dependencies with the name of the sub-project in which
they're defined. I think your idea of a cleaner syntax could be something of
the form:
Depends { names: ["lib1", "lib2"] }
Basically, a condensed syntax that would allow to specify multiple dependency
names in a single depends item, and optionally apply additional properties to
all of those, like so:
Depends { names: ["lib1", "lib2"]; condition: project.hasCoolLibs }
equivalent to:
Depends { name: "lib1"; condition: project.hasCoolLibs }
Depends { name: "lib2"; condition: project.hasCoolLibs }
A "names" property as such would be mutually exclusive with the existing
submodules and productTypes property, as well as the name property.
However your proposal as-is cannot work as the name of a dependency must be the
name of a product or module, and projects have nothing to do with this. I don't
think trying to add them into the mix would make any sense, but I think
something what I suggested above would effectively solve the same problem I
believe you're looking to do so, which is to remove redundant syntax (and my
proposal requires fewer characters too :D).
> On Dec 2, 2017, at 11:27 PM, Christian Gagneraud <[email protected]> wrote:
>
> Hi there,
>
> I would like to know if it's possible to list internal product dependencies
> using the 'submodules' syntax, eg:
>
> MyProduct {
> name: "foo"
> files: [
> ...
> ]
> Depends {
> name: "Qt"
> submodules: [
> ...
> ]
> }
> Depends {
> name: "LibrarySubProject"
> submodules: [ // <=====
> "lib1",
> "lib2"
> ]
> }
> }
>
> Where "LibrarySubProject" is an inline sub-project in the root project and
> lib1, lib2 are internal library products referenced by "SubProject".
> This is different from my "third party" modules defined in
> $qbsSearchPath/modules/ThirdParty/..."
>
>
> I know I can use the Depends { name: "lib1" } form, but for "cosmetic"
> reasons, I would like to use the 'submodules' approach.
>
> You might think that i'm a bit picky, but using this syntax, it makes the
> product.qbs easy to read, pleasant *and* easy to understand.
> That could help me to convince people while show-casing qbs.
>
> I could write one module per library in $qbsSearchPath/modules/ but that
> would be redundant and a bit awkward to maintain.
>
>
> Chris
> _______________________________________________
> Qbs mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/qbs
--
Jake Petroules - [email protected]
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io
_______________________________________________
Qbs mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qbs
