On Tue, 25 Jul 2017 21:13:06 +0200
<resurrect...@centrum.cz> wrote:
> I think I have another possible issue that you may be aware of as well (or I
> am just missing something). The Export item is a great way to control what
> the items that use the Product that defined it recieve. While that direction
> works pretty well I have major
> problems using the properties defined inside the Export in the Product that
> defined it. E.g.:
>
> Product {
> Export {
> Depends { name: "cpp" }
> cpp.includePaths: "include/"
> }
> cpp.defines: MY_SHARED_LIB
> }
>
> This will emit warning that I use "cpp" without depending on it (located on
> the Product).
Correct. The dependencies and properties of the Export item and those of the
containing product are entirely distinct.
>The same warning (located to Export) will happen when I put the Depends before
>Export. Now as per documentation to access the variable defined outside of
>Export one has to use "product.cpp." that seems to work
The canonical way is to use a shared variable, since you generally do not want
to export all your properties (as you've noted yourself):
Product {
// ...
property stringList exportedDefines: ["X"]
property stringList privateDefines: ["Y"]
property stringList commonDefines: ["Z"]
cpp.defines: commonDefines.concat(privateDefines)
Export {
// ...
cpp.defines: product.commonDefines.concat(product.exportedDefines)
}
}
Note how the defines set in the Export item are not a subset of the ones in the
product, nor vice versa.
Do *not* ever export product.cpp.* (whether it seems to work or not), as these
are fully expanded properties, meaning they potentially contain values that
were not set in the product directly, but in modules that the product (but not
the Export item) depends on. That's asking for trouble.
> Another issue that is linked to this one and likely of the same cause
> (whether it is a (known) bug or WAD) that other Depends { name:
> "SomeOtherProduct" } or event Depends { name: "Qt"; submodules: "widgets"; }
> are NOT accessible in the same Product. E.g.:
>
> Product {
> Export {
> Depends { name: "Qt.core" }
> Depends { name: "cpp" }
> cpp.includePaths: "include/"
> }
> cpp.defines: MY_SHARED_LIB
> }
>
> Will provide access to Qt Core to whomever Depends on that Product but it
> does NOT provide access to it to this Product itself. Again, a workaround is
> to Depend on it outside of Export as well. How am I supposed to set these
> properties as exportable while having them available inside the defining
> Product? Ideally without duplicating the same code which I find rather silly.
As Jörg has indicated, there are some ideas of how to make this more
convenient, e.g. by adding a property to the Depends item indicating whether or
not it should be automatically exported.
Christian
_______________________________________________
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
