Re: [Qbs] Relation between Product and Export

[resurrection]

Thanks for the clarification Christian and Joerg! I am looking forward to the 
new version. Let me know if I could help in any way like testing out some 
specific features or so. I like Qbs and what it can do. :-)
Michael
__

Od: Christian Kandeler <christian.kande...@qt.io>
Komu: qbs@qt-project.org
Datum: 26.07.2017 10:39
Předmět: Re: [Qbs] Relation between Product and Export


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 
<http://lists.qt-project.org/mailman/listinfo/qbs>

___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

Re: [Qbs] Relation between Product and Export

[Christian Kandeler]

On Tue, 25 Jul 2017 21:13:06 +0200
 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

Re: [Qbs] Relation between Product and Export

[Joerg Bornemann]

Hi Michael,

indeed, at the moment you have to repeat the Depends items of the 
product in the Export item. This way you can clearly specify what the 
product needs and what users of the product need.


You're right that this looks a bit redundant, and there are thoughts on 
fixing this in QBS-584.



BR,

Joerg
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs

[Qbs] Relation between Product and Export

[resurrection]

Hello,
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). 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 but 
the value does not seem to be properly exported because the other module that depends on this one will not 
have access to the variable by default (as opposed to when both Depends { name: "cpp" } and the 
cpp.includePaths variable are in the Export.
 
Placing all cpp variables into the Export is not an option because as you can probably 
guess the define in the example handles import/export macros so it must NOT be defined 
but in the original Product. One solution is to use Another Depends { name: 
"cpp" } outside of Export but then everything that was set in the Export must 
be repeated outside of it for this other instance as well. Not to mention it looks pretty 
weird:
 
Product {
    Export {
        Depends { name: "cpp" }
        cpp.includePaths: "include/"
    }
    Depends { name: "cpp" }
    cpp.includePaths: "include/"
    cpp.defines: MY_SHARED_LIB
}
 
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.
 
Some further observations regarding this is that if I wanted to expose what I have in Export to 
surrounding Product I would need to explicitely do it with "product." but when another 
product Depends on it the values are "magically" merged to it, e.g.:
 
Product {
    name: "ExportedProduct"
    Export {
        Depends { name: "Qt.core" }
        Depends { name: "cpp" }
        cpp.includePaths: "include/"
    }
    cpp.defines: MY_SHARED_LIB
}
 
Product {
    Depends { name: "cpp" }
    Depends { name: "ExportedProduct" }
    cpp.includePaths: "somePath/"
}
 
Unlike the defining product the importing product does not suffer from any clashes and have all the 
properties readily available without any need to explicitely merge them with its own - like you 
need to do in the defining Product - both "include/" and "somePath/" will be 
passed to the compiler for instance as do other properties. Qt.core will also be available .
 
Perhaps I am missing something important here.
 
Thanks and sorry for longish post!
Michael

___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs