Re: [Qbs] Build QTests from single Product
> On Nov 8, 2017, at 9:12 AM, resurrect...@centrum.cz wrote:
>
> I tried what you suggested and it seems to work without problems:
>
> In common.qbs I created two new properties:
>
> ```
> property stringList files: []`
> property string file
> ```
>
> And modified the internal property:
>
> ```
> readonly property var multiplexMap: ({
> files: "file",
> profiles: "profile",
> architectures: "architecture",
> buildVariants: "buildVariant"
> })
> ```
>
> Now in a product:
> ```
> CppApplication {
> qbs.files: ["main.cpp", "main2.cpp"]
> files: qbs.file
> name: FileInfo.baseName(qbs.file)
>
> }
> ```
>
> And in another in the same project:
> ```
>
> CppApplication {
> qbs.files: ["main3.cpp", "main4.cpp"]
> files: qbs.file
> name: FileInfo.baseName(qbs.file)
>
> }
> ```
>
> Not only this works and builds correctly all 4 executables but there also
> seems to be no errors or clashes even when used in multiple products. And it
> is even correctly picked up by Qt Creator!
>
> As I understand it as common.qbs defines a module its instance is part of
> every single project so they do not affect each other (that is why this
> works). And yes, adding more multiplexing properties seems super easy so I
> really wonder what is it that is stopping you from opening it up for any
> property but I will take your word for it.
Because the qbs module is special. Every module/product has an implicit
dependency on it, and in the implementation it's loaded much earlier than other
modules which leads to its properties having "special privileges".
Other than that, multiplexing is possible for ANY property in the qbs module
(and the case you described is supposed to work without any issue); as I said
the engine has absolutely no inherent knowledge of which properties are
multiplexed, just the mechanism by which it is done.
>
> The only problem I have with this workaround is that it requires editing
> common.qbs that is more than non-standard use but I can live with it for now
> as it gets the job done nicely.
Right, that's the limitation. Regarding your proposal in the next post, I'd
rather make the mechanism itself generic enough to do that across arbitrary
modules, rather than strapping on a new property solely for this purpose.
>
> Thanks!
>
> __
> > Od: Jake Petroules <jake.petrou...@qt.io>
> > Komu: "resurrect...@centrum.cz" <resurrect...@centrum.cz>
> > Datum: 08.11.2017 17:15
> > Předmět: Re: [Qbs] Build QTests from single Product
> >
> > CC: <qbs@qt-project.org>
> The simple answer is that multiplexing is limited to those 3 properties right
> now for technical reasons. In terms of the design concept, I certainly would
> have liked to allow it to work over ANY property, but we ran into limitations
> with the implementation.
>
> At least right now, it's technically possible to add an unlimited number of
> multiplexing axes simply by modifying common.qbs (i.e. it requires no changes
> to the engine), but only properties of the qbs module can be multiplexed, not
> others. So something like Product.files/Group.files is out of the question at
> least for now.
>
> If you can argue for multiplexing over a particular qbs module property, feel
> free to propose a patch and we may consider adding it.
>
> > On Nov 8, 2017, at 12:28 AM, resurrect...@centrum.cz wrote:
> >
> > In other testing frameworks like Google Test the test executable typically
> > contains all test cases for the given module under test so there typically
> > are as many products for tests as there are production modules. With QTest
> > this is unsupported (although doable) and for good reasons too (mainly
> > separation of test runs). As a result this requires each test case to be a
> > separate executable and thus a separate Product under Qbs. While some code
> > duplicity could be avoided by extracting most of the qbs code into custom
> > item and instantiating that, the issue of the project list and the running
> > executable(s) lists will be absolutely cluttered with every class being a
> > separate Product (think Qt itself or even Qt Creator projects). Now the
> > multiplexing sounds just like the right thing for this as one could pass
> > the `files` property to `multiplexByQbsProperties` and it should work as
> > expected building an executable for each file. Unfortunately that is not
> > currently possible as `m ult
Re: [Qbs] Build QTests from single Product
And in fact I do have a suggestion, what about new property in the common.qbs:
property var userValues: []
property var userValue
readonly property var multiplexMap: ({
userValues: "userValue",
profiles: "profile",
With this one could multiplex over pretty much anything as in any Product the userValues
could be populated with objects of arbitrary structure and then qbs.userValue would
contain that object if multiplexByQbsProperties: ["userValues"] was set.
Not sure how invasive or potentially problematic this change would be but I
would happilly submit a patch if you think it worthwhile.
__
Od: Jake Petroules <jake.petrou...@qt.io>
Komu: "resurrect...@centrum.cz" <resurrect...@centrum.cz>
Datum: 08.11.2017 17:15
Předmět: Re: [Qbs] Build QTests from single Product
CC: <qbs@qt-project.org>
The simple answer is that multiplexing is limited to those 3 properties right
now for technical reasons. In terms of the design concept, I certainly would
have liked to allow it to work over ANY property, but we ran into limitations
with the implementation.
At least right now, it's technically possible to add an unlimited number of
multiplexing axes simply by modifying common.qbs (i.e. it requires no changes
to the engine), but only properties of the qbs module can be multiplexed, not
others. So something like Product.files/Group.files is out of the question at
least for now.
If you can argue for multiplexing over a particular qbs module property, feel
free to propose a patch and we may consider adding it.
> On Nov 8, 2017, at 12:28 AM, resurrect...@centrum.cz wrote:
>
> In other testing frameworks like Google Test the test executable typically contains all test cases for the given module under test so there typically are as many products for tests as there are production modules. With QTest this is unsupported (although doable) and for good reasons too (mainly separation of test runs). As a result this requires each test case to be a separate executable and thus a separate Product under Qbs. While some code duplicity could be avoided by extracting most of the qbs code into custom item and instantiating that, the issue of the project list and the running executable(s) lists will be absolutely cluttered with every class being a separate Product (think Qt itself or even Qt Creator projects). Now the multiplexing sounds just like the right thing for this as one could pass the `files` property to `multiplexByQbsProperties` and it should work as expected building an executable for each file. Unfortunately that is not currently possible as `mult
ipl
> exByQbsP
> roperties` is limited only to one of `["architectures", "buildVariants",
"profiles"]`.
>
> Incidentally this hints towards what I would absolutely love to see in Qbs and that is kind of there but not quite - dynamically defined Products. The multiplexing is just that - you defined a product and told Qbs to build it n times with these different settings. Custom items are almost that with the big limitation that you have to actually instantiate them manually rather than based on some property(ies). The QTest issue is a variation on this: "build this Product for every file in this list". Currently I need to go and instantiate the custom item manually for each test case. And it could be pushed a bit further by being able to say build this Product for every directory in this list with files being extracted dynamically etc. That would essentially remove the raison d'être for the qbs-autoproject that is doing exactly that - moving from manually defining each product to defining rules for a product type/category letting the build system to extract the project/products
and
> build t
> hem.
>
> So my ultimate question I guess is what are the plans regarding multiplexing?
Will it be expanded into more general Qbs feature or kept limited to the special
(Apple mainly) use case(s)? And what about the QTests?
>
> Best wishes,
> Michael
> ___
> Qbs mailing list
> Qbs@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qbs
<http://lists.qt-project.org/mailman/listinfo/qbs>
--
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Build QTests from single Product
I tried what you suggested and it seems to work without problems:
In common.qbs I created two new properties:
```
property stringList files: []`
property string file
```
And modified the internal property:
```
readonly property var multiplexMap: ({
files: "file",
profiles: "profile",
architectures: "architecture",
buildVariants: "buildVariant"
})
```
Now in a product:
```
CppApplication {qbs.files: ["main.cpp", "main2.cpp"]files: qbs.file
name: FileInfo.baseName(qbs.file)}``` And in another in the same project:```
CppApplication {qbs.files: ["main3.cpp", "main4.cpp"]files: qbs.file
name: FileInfo.baseName(qbs.file)}``` Not only this works and builds correctly all 4 executables
but there also seems to be no errors or clashes even when used in multiple products. And it is even
correctly picked up by Qt Creator! As I understand it as common.qbs defines a module its instance
is part of every single project so they do not affect each other (that is why this works). And yes,
adding more multiplexing properties seems super easy so I really wonder what is it that is stopping
you from opening it up for any property but I will take your word for it. The only problem I have
with this workaround is that it requires editing common.qbs that is more than non-standard use but
I can live with it for now as it gets the job done nicely. Thanks!
__
Od: Jake Petroules <jake.petrou...@qt.io>
Komu: "resurrect...@centrum.cz" <resurrect...@centrum.cz>
Datum: 08.11.2017 17:15
Předmět: Re: [Qbs] Build QTests from single Product
CC: <qbs@qt-project.org>
The simple answer is that multiplexing is limited to those 3 properties right
now for technical reasons. In terms of the design concept, I certainly would
have liked to allow it to work over ANY property, but we ran into limitations
with the implementation.
At least right now, it's technically possible to add an unlimited number of
multiplexing axes simply by modifying common.qbs (i.e. it requires no changes
to the engine), but only properties of the qbs module can be multiplexed, not
others. So something like Product.files/Group.files is out of the question at
least for now.
If you can argue for multiplexing over a particular qbs module property, feel
free to propose a patch and we may consider adding it.
> On Nov 8, 2017, at 12:28 AM, resurrect...@centrum.cz wrote:
>
> In other testing frameworks like Google Test the test executable typically contains all test cases for the given module under test so there typically are as many products for tests as there are production modules. With QTest this is unsupported (although doable) and for good reasons too (mainly separation of test runs). As a result this requires each test case to be a separate executable and thus a separate Product under Qbs. While some code duplicity could be avoided by extracting most of the qbs code into custom item and instantiating that, the issue of the project list and the running executable(s) lists will be absolutely cluttered with every class being a separate Product (think Qt itself or even Qt Creator projects). Now the multiplexing sounds just like the right thing for this as one could pass the `files` property to `multiplexByQbsProperties` and it should work as expected building an executable for each file. Unfortunately that is not currently possible as `mult
ipl
> exByQbsP
> roperties` is limited only to one of `["architectures", "buildVariants",
"profiles"]`.
>
> Incidentally this hints towards what I would absolutely love to see in Qbs and that is kind of there but not quite - dynamically defined Products. The multiplexing is just that - you defined a product and told Qbs to build it n times with these different settings. Custom items are almost that with the big limitation that you have to actually instantiate them manually rather than based on some property(ies). The QTest issue is a variation on this: "build this Product for every file in this list". Currently I need to go and instantiate the custom item manually for each test case. And it could be pushed a bit further by being able to say build this Product for every directory in this list with files being extracted dynamically etc. That would essentially remove the raison d'être for the qbs-autoproject that is doing exactly that - moving from manually defining each product to defining rules for a product type/category letting the build system to extract the project/products
and
> build t
> hem.
>
> So my ultimate question I guess is what are the plans regarding multiplexing?
Will it be expanded into more general Qbs feature or kept limited to the special
(Apple mainly) use case(s)? And what about the QTests?
>
[Qbs] Build QTests from single Product
In other testing frameworks like Google Test the test executable typically contains all test cases for the given module under test so there typically are as many products for tests as there are production modules. With QTest this is unsupported (although doable) and for good reasons too (mainly separation of test runs). As a result this requires each test case to be a separate executable and thus a separate Product under Qbs. While some code duplicity could be avoided by extracting most of the qbs code into custom item and instantiating that, the issue of the project list and the running executable(s) lists will be absolutely cluttered with every class being a separate Product (think Qt itself or even Qt Creator projects). Now the multiplexing sounds just like the right thing for this as one could pass the `files` property to `multiplexByQbsProperties` and it should work as expected building an executable for each file. Unfortunately that is not currently possible as `multipl exByQbsP roperties` is limited only to one of `["architectures", "buildVariants", "profiles"]`. Incidentally this hints towards what I would absolutely love to see in Qbs and that is kind of there but not quite - dynamically defined Products. The multiplexing is just that - you defined a product and told Qbs to build it n times with these different settings. Custom items are almost that with the big limitation that you have to actually instantiate them manually rather than based on some property(ies). The QTest issue is a variation on this: "build this Product for every file in this list". Currently I need to go and instantiate the custom item manually for each test case. And it could be pushed a bit further by being able to say build this Product for every directory in this list with files being extracted dynamically etc. That would essentially remove the raison d'être for the qbs-autoproject that is doing exactly that - moving from manually defining each product to defining rules for a product type/category letting the build system to extract the project/products and build t hem. So my ultimate question I guess is what are the plans regarding multiplexing? Will it be expanded into more general Qbs feature or kept limited to the special (Apple mainly) use case(s)? And what about the QTests? Best wishes, Michael ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
