Re: [Qbs] "Multi" Properties
OK, understood.
Thank you!
18.12.2017 14:15, Christian Kandeler пишет:
On Mon, 18 Dec 2017 14:04:21 +0300
Карелин Павел wrote:
In my project, I use the following construction:
cpp.defines: {
var def = [];
if (project.simdDebug)
def.push("SIMD_DEBUG");
if (project.useSimd)
def.push("USE_SIMD");
return def;
}
It works fine.
But I decided to experiment and do the same through "Properties"
Properties {
condition: project.simdDebug
cpp.defines: outer.concat(["SIMD_DEBUG"])
}
Properties {
condition: project.useSimd
cpp.defines: outer.concat(["USE_SIMD"])
}
As a result, I get either SIMD_DEBUG or USE_SIMD at the output, but not
both at once.
Is it possible to get both values immediately using "Properties"?
No, the Properties items form an implicit "else if" chain, so the conditions
should be mutually exclusive if the same property appears in more than one of them. They
are not well-suited for additive semantics like in your example.
Christian
___
Qbs mailing list
Qbs@qt-project.org
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] "Multi" Properties
On Mon, 18 Dec 2017 14:04:21 +0300
Карелин Павел wrote:
> In my project, I use the following construction:
>
> cpp.defines: {
> var def = [];
> if (project.simdDebug)
> def.push("SIMD_DEBUG");
>
> if (project.useSimd)
> def.push("USE_SIMD");
>
> return def;
> }
>
> It works fine.
> But I decided to experiment and do the same through "Properties"
>
> Properties {
> condition: project.simdDebug
> cpp.defines: outer.concat(["SIMD_DEBUG"])
> }
> Properties {
> condition: project.useSimd
> cpp.defines: outer.concat(["USE_SIMD"])
> }
>
> As a result, I get either SIMD_DEBUG or USE_SIMD at the output, but not
> both at once.
> Is it possible to get both values immediately using "Properties"?
No, the Properties items form an implicit "else if" chain, so the conditions
should be mutually exclusive if the same property appears in more than one of
them. They are not well-suited for additive semantics like in your example.
Christian
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
[Qbs] "Multi" Properties
Hi,
In my project, I use the following construction:
cpp.defines: {
var def = [];
if (project.simdDebug)
def.push("SIMD_DEBUG");
if (project.useSimd)
def.push("USE_SIMD");
return def;
}
It works fine.
But I decided to experiment and do the same through "Properties"
Properties {
condition: project.simdDebug
cpp.defines: outer.concat(["SIMD_DEBUG"])
}
Properties {
condition: project.useSimd
cpp.defines: outer.concat(["USE_SIMD"])
}
As a result, I get either SIMD_DEBUG or USE_SIMD at the output, but not
both at once.
Is it possible to get both values immediately using "Properties"?
--
BR, Pavel Karelin
___
Qbs mailing list
Qbs@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] QT_DEBUG defined on release builds
Could a warning be emitted on value overwrites though? Christian raises a very valid point of these errors being kinda difficult to trace. Obviously there will need to be a way to say to qbs that this write is valid to silence the warning though. On Mon, Dec 18, 2017 at 1:21 PM, Christian Kandeler < christian.kande...@qt.io> wrote: > On Sun, 17 Dec 2017 08:53:42 +1300 > Christian Gagneraud wrote: > > > Could someone explain the rules as to when to use base.concat or not, eg > is > > it necessary here just because of the group? Or should this be always > used? > > (Project, Product, Module, ...) > > You use "base" if and only if there is a base item that sets the > respective property and you want to merge the values. This happens often in > products, but if you find yourself deriving from a Module or Group item, > then the same logic also applies. > When setting module properties in a (non-derived) Group, you'll typically > use "outer" instead, which refers to the value in the surrounding product. > That should do the right thing even if the product does not set the module > property directly. > See also https://doc.qt.io/qbs/module-item.html#special-property-values > > > Christian > ___ > Qbs mailing list > Qbs@qt-project.org > 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] QT_DEBUG defined on release builds
On Sun, 17 Dec 2017 08:53:42 +1300 Christian Gagneraud wrote: > Could someone explain the rules as to when to use base.concat or not, eg is > it necessary here just because of the group? Or should this be always used? > (Project, Product, Module, ...) You use "base" if and only if there is a base item that sets the respective property and you want to merge the values. This happens often in products, but if you find yourself deriving from a Module or Group item, then the same logic also applies. When setting module properties in a (non-derived) Group, you'll typically use "outer" instead, which refers to the value in the surrounding product. That should do the right thing even if the product does not set the module property directly. See also https://doc.qt.io/qbs/module-item.html#special-property-values Christian ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
Re: [Qbs] Fwd: qbs run --dry-run not working ?
> VSCode is actually one of the reasons why I brought up a qbs "server mode" > that would just use REST APIs for IDE integration (including solving the > compatibility issue for Qt Creator). I would love to see something like this :) > > On Dec 15, 2017, at 5:33 AM, Heiko Nardmann < > heiko.nardm...@itechnical.de> wrote: > > > > How about accessing the QBS API DLL from within Typescript? > > > > I must admit that I have no idea wrt. the capabilities of Typescript. > Maybe you need some wrapper DLL between Typescript and the QBS C++ DLL? > > > > > > Kind regards, > > > > Heiko > > > > Am 15.12.2017 um 13:55 schrieb Damien Courtois: > >> Yes I have seen his reply and took the time to check the Qbs > repository, but that's not what I'm trying to do. What I'm trying to do is > basically what Qt Creator is doing with CMake. > >> > >> To elaborate further: I don't want to generate a solution/whatever and > then open this solution/whatever with my IDE. I just want to use the Qbs > command line tool to build, clean and debug a Qbs project, without > resorting to (e.g. generate) non-qbs-native files. > >> And it's pretty much doable, but like with CMake before its server > mode, it relies on a lot of parsing Qbs command line tool outputs, and this > is not very reliable nor future proof, thus the idea of a clear query > command in the command line tool :) > >> > >> I hope it's a bit clearer :) > >> > >> 2017-12-15 12:12 GMT+01:00 Christian Kandeler >: > >> On Fri, 15 Dec 2017 11:41:04 +0100 > >> Damien Courtois wrote: > >> > >> > -- Forwarded message -- > >> > From: Damien Courtois > >> > Date: 2017-12-15 11:39 GMT+01:00 > >> > Subject: Re: [Qbs] qbs run --dry-run not working ? > >> > To: Christian Kandeler > >> > Cc: "qbs@qt-project.org\" "@qt-project.org > >> > > >> > > >> > The IDE is VSCode. And since extensions are typescript modules, I can > only > >> > use the Qbs command line tool. > >> > > >> > I understand that the command line tool was not designed for being > used > >> > like this, but I think that if it provided a command to query > informations > >> > about a project, it would really ease integration into a lot of > tools. Take > >> > the example of CMake: it's integrated in Qt Creator, and now even in > Visual > >> > Studio 2017. This integration was possible by parsing the output of > CMake, > >> > and since the server mode, it became even easier (well, at least now > it's > >> > standardized. I still don't understand why they had to create the > whole > >> > server mode / handshake / whatever mess instead of just outputting > things > >> > directly, but anyways :p) > >> > > >> > Is this something you would consider ? And if this is not your > priority > >> > (which I would totally understand) are you accepting contributions ? > >> > >> Have you seen Jake's reply about project generators? It may well be > that qbs producing native project files is the better alternative here. I'm > not too knowledgeable about either our generator stuff or about VSCode, so > I suggest you discuss your requirements with him. > >> If it turns out that that's not the right approach, we can come back to > the command line tool. > >> > >> > >> Christian > > > > > > ___ > > Qbs mailing list > > Qbs@qt-project.org > > 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 > ___ Qbs mailing list Qbs@qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs
