From christian.kandeler at qt.io Mon Aug 1 09:20:51 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 1 Aug 2016 09:20:51 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: References: Message-ID: On 07/29/2016 09:05 PM, Dennis Tomas wrote: > Rule { > property string fileName: "resources" > multiplex: true > Artifact { > filePath: baseName + ".qrc" // ReferenceError > fileTags: ["qrc"] > } > prepare: { > [...] > } > } > > I get a ReferenceError as marked above. Is there a way to somehow > reference baseName from the Artifact's filePath property? Have you tried parent.baseName? Christian From den.t at gmx.de Mon Aug 1 10:24:21 2016 From: den.t at gmx.de (Dennis Tomas) Date: Mon, 1 Aug 2016 10:24:21 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: References: Message-ID: Am 01.08.2016 um 09:20 schrieb Christian Kandeler: > On 07/29/2016 09:05 PM, Dennis Tomas wrote: >> Rule { >> property string fileName: "resources" >> multiplex: true >> Artifact { >> filePath: baseName + ".qrc" // ReferenceError >> fileTags: ["qrc"] >> } >> prepare: { >> [...] >> } >> } >> >> I get a ReferenceError as marked above. Is there a way to somehow >> reference baseName from the Artifact's filePath property? > > Have you tried parent.baseName? > Yes, this also results in a ReferenceError. I've also tried setting 'id: rule' on the rule and referencing 'rule.baseName' in the Artifact, leading to a ReferenceError as well. From thomas.epting at stryker.com Tue Aug 2 09:34:25 2016 From: thomas.epting at stryker.com (Epting, Thomas) Date: Tue, 2 Aug 2016 03:34:25 -0400 Subject: [QBS] Regression with Qbs 1.6 and Bullseye Coverage Message-ID: <854A47713007BC4096CB1E36057406E11EB18FC832@SYKMAIL9.strykercorp.com> We're using a tool called Bullseye Coverage for measuring code coverage with Visual Studio compilers on Windows. When the Bullseye "integration" for Visual Studio compilers is enabled, the installer adds one line to the end of each of the vcvarsXX.bat files in /VC/bin: @set PATH=c:/BullseyeCoverage/bin;%PATH% The Bullseye bin folder contains a specific version of the compiler shell (cl.exe) which does some source code preprocessing in case Bullseye instrumentation is active at the moment. In any case the original compiler shell from the next occurrence in PATH is called to do the actual work. This approach is working fine with Qbs, but since Qbs 1.6 (as contained in QtCreator 4.1 beta) we observe a major regression. With Bullseye integration on (which means the PATH modification in the .bat files is active), Qbs refuses to load the project and reports: <...>\MsvcProbe.qbs:47: error: Error: Detecting the MSVC build environment failed: Cannot find 'C:\BullseyeCoverage\vcvarsall.bat'. Is this problem already known, is there a workaround or should I create a Jira issue? Best regards, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Tue Aug 2 11:17:13 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 2 Aug 2016 11:17:13 +0200 Subject: [QBS] Regression with Qbs 1.6 and Bullseye Coverage In-Reply-To: <854A47713007BC4096CB1E36057406E11EB18FC832@SYKMAIL9.strykercorp.com> References: <854A47713007BC4096CB1E36057406E11EB18FC832@SYKMAIL9.strykercorp.com> Message-ID: <7e4c68a1-6432-a2b2-f981-c3154de990d7@qt.io> On 08/02/2016 09:34 AM, Epting, Thomas wrote: > We’re using a tool called Bullseye Coverage for measuring code coverage > with Visual Studio compilers on Windows. > > When the Bullseye "integration" for Visual Studio compilers is enabled, > the installer adds one line to the end of each of the vcvarsXX.bat files > in ///VC/bin: > > @setPATH=c:/BullseyeCoverage/bin;%PATH% > > The Bullseye bin folder contains a specific version of the compiler > shell (cl.exe) which does some source code preprocessing in case > Bullseye instrumentation is active at the moment. In any case the > original compiler shell from the /next/ occurrence in PATH is called to > do the actual work. > > This approach is working fine with Qbs, Are you sure that it was ever working with this particular compiler executable? AFAIK the bat file was always looked up relative to cl.exe. So calling setup-toolchains --detect using above PATH should have complained in 1.5... > but since Qbs 1.6 (as contained > in QtCreator 4.1 beta) we observe a major regression. With Bullseye > integration on (which means the PATH modification in the .bat files is > active), Qbs refuses to load the project and reports: > > <...>\MsvcProbe.qbs:47: error: Error: Detecting the MSVC build > environment failed: Cannot find 'C:\BullseyeCoverage\vcvarsall.bat'. ... with this message. > Is this problem already known, is there a workaround or should I create > a Jira issue? Please create an issue. Christian From thomas.epting at stryker.com Tue Aug 2 12:28:50 2016 From: thomas.epting at stryker.com (Epting, Thomas) Date: Tue, 2 Aug 2016 06:28:50 -0400 Subject: [QBS] Regression with Qbs 1.6 and Bullseye Coverage In-Reply-To: <7e4c68a1-6432-a2b2-f981-c3154de990d7@qt.io> References: <854A47713007BC4096CB1E36057406E11EB18FC832@SYKMAIL9.strykercorp.com> <7e4c68a1-6432-a2b2-f981-c3154de990d7@qt.io> Message-ID: <854A47713007BC4096CB1E36057406E11EB18FC84E@SYKMAIL9.strykercorp.com> > > When the Bullseye "integration" for Visual Studio compilers is > > enabled, the installer adds one line to the end of each of the > > vcvarsXX.bat files in ///VC/bin: > > > > @setPATH=c:/BullseyeCoverage/bin;%PATH% > > Are you sure that it was ever working with this particular compiler executable? AFAIK the bat file was always looked up relative to cl.exe. > So calling setup-toolchains --detect using above PATH should have complained in 1.5... Yes, we've been using it for about a year now (I think since QtCreator 3.6). > > <...>\MsvcProbe.qbs:47: error: Error: Detecting the MSVC build > > environment failed: Cannot find 'C:\BullseyeCoverage\vcvarsall.bat'. Interestingly, if doing it all manually (without QtCreator) it seems to work. >>> qbs --version 1.6.0 >>> qbs config --settings-dir c:\tmp\qbs16 --list >>> qbs setup-toolchains --settings-dir c:\tmp\qbs16 --type msvc c:\programs\mvs12\vc\bin\cl.exe mvs12 Setting up profile 'mvs12'. Profile 'mvs12' created for 'C:\programs\mvs12\vc\bin\cl.exe'. >>> qbs config --settings-dir c:\tmp\qbs16 --list profiles.mvs12.cpp.compilerVersionMajor: "18" profiles.mvs12.cpp.toolchainInstallPath: "C:/programs/mvs12/vc/bin" profiles.mvs12.qbs.architecture: "x86" profiles.mvs12.qbs.targetOS: "windows" profiles.mvs12.qbs.toolchain: "msvc" >>> qbs build --file c:\tmp\demo.qbs --settings-dir c:\tmp\qbs15 debug profile:mvs12 No build graph exists yet for this configuration. Resolving project for configuration debug Setting up build graph for configuration debug Building for configuration debug compiling main.cpp linking demo.exe embedding manifest into demo.exe Build done for configuration debug. In QtCreator with a similar kit however, opening the same project results in the error message from MsvcProbe. So I assume the problem is more related to QtCreator? > > Is this problem already known, is there a workaround or should I > > create a Jira issue? > > Please create an issue. Should it be created in Qbs or QtCreator project? Thanks, Thomas --- demo.qbs --- import qbs CppApplication { name: "demo" files: "main.cpp" } --- main.cpp --- #include int main() { std::cout << "hello, world\n"; } From christian.kandeler at qt.io Tue Aug 2 12:29:34 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 2 Aug 2016 12:29:34 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: References: Message-ID: On 08/01/2016 10:24 AM, Dennis Tomas wrote: > Am 01.08.2016 um 09:20 schrieb Christian Kandeler: >> On 07/29/2016 09:05 PM, Dennis Tomas wrote: >>> Rule { >>> property string fileName: "resources" >>> multiplex: true >>> Artifact { >>> filePath: baseName + ".qrc" // ReferenceError >>> fileTags: ["qrc"] >>> } >>> prepare: { >>> [...] >>> } >>> } >>> >>> I get a ReferenceError as marked above. Is there a way to somehow >>> reference baseName from the Artifact's filePath property? >> >> Have you tried parent.baseName? >> > Yes, this also results in a ReferenceError. Ah yes. That's because the filePath property is evaluated in a different context and at a later stage (so that you can refer to "inputs", for instance). This means your approach cannot work as is; you'll have to look for a different way to set your output file name. There are lots of possibilities; for instance, you could derive it from the name of the first input artifact. It just has to be unique. Christian From thomas.epting at stryker.com Tue Aug 2 17:31:35 2016 From: thomas.epting at stryker.com (Epting, Thomas) Date: Tue, 2 Aug 2016 11:31:35 -0400 Subject: [QBS] Regression with Qbs 1.6 and Bullseye Coverage References: <854A47713007BC4096CB1E36057406E11EB18FC832@SYKMAIL9.strykercorp.com> <7e4c68a1-6432-a2b2-f981-c3154de990d7@qt.io> Message-ID: <854A47713007BC4096CB1E36057406E11EB18FC90C@SYKMAIL9.strykercorp.com> > Please create an issue. https://bugreports.qt.io/browse/QBS-1000 Cool, I got the 1000 :-) From den.t at gmx.de Fri Aug 5 13:40:32 2016 From: den.t at gmx.de (Dennis Tomas) Date: Fri, 5 Aug 2016 13:40:32 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: References: Message-ID: <57A47B30.60704@gmx.de> Am 02.08.2016 um 12:29 schrieb Christian Kandeler: > On 08/01/2016 10:24 AM, Dennis Tomas wrote: >> Am 01.08.2016 um 09:20 schrieb Christian Kandeler: >>> On 07/29/2016 09:05 PM, Dennis Tomas wrote: >>>> Rule { >>>> property string fileName: "resources" >>>> multiplex: true >>>> Artifact { >>>> filePath: baseName + ".qrc" // ReferenceError >>>> fileTags: ["qrc"] >>>> } >>>> prepare: { >>>> [...] >>>> } >>>> } >>>> >>>> I get a ReferenceError as marked above. Is there a way to somehow >>>> reference baseName from the Artifact's filePath property? >>> >>> Have you tried parent.baseName? >>> >> Yes, this also results in a ReferenceError. > > Ah yes. That's because the filePath property is evaluated in a > different context and at a later stage (so that you can refer to > "inputs", for instance). This means your approach cannot work as is; > you'll have to look for a different way to set your output file name. > There are lots of possibilities; for instance, you could derive it > from the name of the first input artifact. It just has to be unique. > In my case it's not sufficient for the name to be unique, because I have to reference it when using the Q_INIT_RESOURCE macro. Is it technically possible to solve this in Qbs, i.e. by somehow injecting the Rule property values into the context of the Artifact? From christian.kandeler at qt.io Fri Aug 5 13:55:42 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 5 Aug 2016 13:55:42 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: <57A47B30.60704@gmx.de> References: <57A47B30.60704@gmx.de> Message-ID: <9bfaa0c8-2899-5cf6-3f34-71c5894eafc2@qt.io> On 08/05/2016 01:40 PM, Dennis Tomas wrote: > Am 02.08.2016 um 12:29 schrieb Christian Kandeler: >> On 08/01/2016 10:24 AM, Dennis Tomas wrote: >>> Am 01.08.2016 um 09:20 schrieb Christian Kandeler: >>>> On 07/29/2016 09:05 PM, Dennis Tomas wrote: >>>>> Rule { >>>>> property string fileName: "resources" >>>>> multiplex: true >>>>> Artifact { >>>>> filePath: baseName + ".qrc" // ReferenceError >>>>> fileTags: ["qrc"] >>>>> } >>>>> prepare: { >>>>> [...] >>>>> } >>>>> } >>>>> >>>>> I get a ReferenceError as marked above. Is there a way to somehow >>>>> reference baseName from the Artifact's filePath property? >>>> >>>> Have you tried parent.baseName? >>>> >>> Yes, this also results in a ReferenceError. >> >> Ah yes. That's because the filePath property is evaluated in a >> different context and at a later stage (so that you can refer to >> "inputs", for instance). This means your approach cannot work as is; >> you'll have to look for a different way to set your output file name. >> There are lots of possibilities; for instance, you could derive it >> from the name of the first input artifact. It just has to be unique. >> > In my case it's not sufficient for the name to be unique, because I have > to reference it when using the Q_INIT_RESOURCE macro. In that case, I suggest that you represent the qrc files as products and let your rule derive the file name from product.targetName. Christian From den.t at gmx.de Fri Aug 5 18:45:53 2016 From: den.t at gmx.de (Dennis Tomas) Date: Fri, 5 Aug 2016 18:45:53 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: <9bfaa0c8-2899-5cf6-3f34-71c5894eafc2@qt.io> References: <57A47B30.60704@gmx.de> <9bfaa0c8-2899-5cf6-3f34-71c5894eafc2@qt.io> Message-ID: <57A4C2C1.8000701@gmx.de> Am 05.08.2016 um 13:55 schrieb Christian Kandeler: > On 08/05/2016 01:40 PM, Dennis Tomas wrote: >> Am 02.08.2016 um 12:29 schrieb Christian Kandeler: >>> On 08/01/2016 10:24 AM, Dennis Tomas wrote: >>>> Am 01.08.2016 um 09:20 schrieb Christian Kandeler: >>>>> On 07/29/2016 09:05 PM, Dennis Tomas wrote: >>>>>> Rule { >>>>>> property string fileName: "resources" >>>>>> multiplex: true >>>>>> Artifact { >>>>>> filePath: baseName + ".qrc" // ReferenceError >>>>>> fileTags: ["qrc"] >>>>>> } >>>>>> prepare: { >>>>>> [...] >>>>>> } >>>>>> } >>>>>> >>>>>> I get a ReferenceError as marked above. Is there a way to somehow >>>>>> reference baseName from the Artifact's filePath property? >>>>> >>>>> Have you tried parent.baseName? >>>>> >>>> Yes, this also results in a ReferenceError. >>> >>> Ah yes. That's because the filePath property is evaluated in a >>> different context and at a later stage (so that you can refer to >>> "inputs", for instance). This means your approach cannot work as is; >>> you'll have to look for a different way to set your output file name. >>> There are lots of possibilities; for instance, you could derive it >>> from the name of the first input artifact. It just has to be unique. >>> >> In my case it's not sufficient for the name to be unique, because I have >> to reference it when using the Q_INIT_RESOURCE macro. > > In that case, I suggest that you represent the qrc files as products > and let your rule derive the file name from product.targetName. > Thanks. Now I have a custom product item Qrc.qbs: StaticLibrary { property stringList inputs Rule { inputs: product.inputs Artifact { filePath: product.targetName + ".qrc" fileTags: ["qrc"] } prepare: { [...] } } Depends { name: "Qt.core" } } and extend it in translations.qbs and qml.qbs: Qrc { name: "foo-translations" files: ["translations/*.ts"] inputs: ["qm"] } Qrc { name: "foo-qml" Group { files: "qml/**" fileTags: ["qml"] } inputs: ["qml"] } The product foo depends on foo-translations and foo-qml. It works, but I'd really like it to be less verbose (I have a large number of products in my project, each having one or more resource files to be generated). I've hacked Qbs to make the rule available to the output artifact and the prepare function: https://github.com/dtomas/qbs/commit/716cc901b124903866a3ba1370e1085804342d8d What do you think of it? Regards, Dennis From christian.kandeler at qt.io Mon Aug 8 11:37:10 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 8 Aug 2016 11:37:10 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: <57A4C2C1.8000701@gmx.de> References: <57A47B30.60704@gmx.de> <9bfaa0c8-2899-5cf6-3f34-71c5894eafc2@qt.io> <57A4C2C1.8000701@gmx.de> Message-ID: <0b87df46-24ec-0be4-65dd-505d351419e6@qt.io> On 08/05/2016 06:45 PM, Dennis Tomas wrote: > I've hacked Qbs to make the rule available to the output artifact and > the prepare function: > https://github.com/dtomas/qbs/commit/716cc901b124903866a3ba1370e1085804342d8d > > What do you think of it? I'm not sure. The evaluation depends on whether we think of multiplex rules whose output artifact has a fixed name, but is not a product target artifact, as exotic or not. You might want to file a suggestion in JIRA about making user-provided rule properties available at rule execution time. Meanwhile, here's another idea for your concrete use case: Let the product provide a mapping between file tags and output file names: Product { property var tagMap: ({ qm: "translations", assets: "assets", /* ... */}) // ... } Rule { Artifact { filePath: product.tagMap[Object.keys(inputs)[0]] + ".qrc" fileTags: "qrc" } // ... } Ths should be exactly what you want, I think. Christian From den.t at gmx.de Wed Aug 10 15:05:39 2016 From: den.t at gmx.de (Dennis Tomas) Date: Wed, 10 Aug 2016 15:05:39 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: <0b87df46-24ec-0be4-65dd-505d351419e6@qt.io> References: <57A47B30.60704@gmx.de> <9bfaa0c8-2899-5cf6-3f34-71c5894eafc2@qt.io> <57A4C2C1.8000701@gmx.de> <0b87df46-24ec-0be4-65dd-505d351419e6@qt.io> Message-ID: <20160810150539.5648313d@dt-Aspire-7250> Am Mon, 8 Aug 2016 11:37:10 +0200 schrieb Christian Kandeler : > On 08/05/2016 06:45 PM, Dennis Tomas wrote: > > I've hacked Qbs to make the rule available to the output artifact > > and the prepare function: > > https://github.com/dtomas/qbs/commit/716cc901b124903866a3ba1370e1085804342d8d > > > > What do you think of it? > > I'm not sure. The evaluation depends on whether we think of multiplex > rules whose output artifact has a fixed name, but is not a product > target artifact, as exotic or not. Passing a file name is one use case for parametrizing a rule, but there might be others, such as passing different command line flags etc. > You might want to file a > suggestion in JIRA about making user-provided rule properties > available at rule execution time. Done: https://bugreports.qt.io/browse/QBS-1003 > Meanwhile, here's another idea for your concrete use case: Let the > product provide a mapping between file tags and output file names: > > Product { > property var tagMap: ({ qm: "translations", assets: "assets", /* > ... */}) > // ... > } > > Rule { > Artifact { > filePath: product.tagMap[Object.keys(inputs)[0]] + ".qrc" > fileTags: "qrc" > } > // ... > } > > Ths should be exactly what you want, I think. > Thank you. It feels somewhat dirty, but seems to work. Another approach I've tried, but which hasn't worked, was putting the rule into a module named "qrc": Product { Group { fileTags: "qm" qrc.inputs: "qm" qrc.baseName: "translations" } Group { files: "assets/**" fileTags: "asset" qrc.inputs: "asset" qrc.baseName: "assets" } Depends { name: "qrc" } [...] } I thought that module properties could be overridden per Group like that (like qbs.installDir), but it seems I'm wrong here. When trying to access them in the output Artifact of the module's rule (using product.moduleProperty()) they are always undefined. Or is this a similar problem as with the Rule properties? Regards, Dennis From christian.kandeler at qt.io Wed Aug 10 15:55:59 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 10 Aug 2016 15:55:59 +0200 Subject: [QBS] Referencing Rule properties In-Reply-To: <20160810150539.5648313d@dt-Aspire-7250> References: <57A47B30.60704@gmx.de> <9bfaa0c8-2899-5cf6-3f34-71c5894eafc2@qt.io> <57A4C2C1.8000701@gmx.de> <0b87df46-24ec-0be4-65dd-505d351419e6@qt.io> <20160810150539.5648313d@dt-Aspire-7250> Message-ID: On 08/10/2016 03:05 PM, Dennis Tomas wrote: > Another approach I've tried, but which hasn't worked, was putting the > rule into a module named "qrc": > > Product { > Group { > fileTags: "qm" > qrc.inputs: "qm" > qrc.baseName: "translations" > } > Group { > files: "assets/**" > fileTags: "asset" > qrc.inputs: "asset" > qrc.baseName: "assets" > } > Depends { name: "qrc" } > [...] > } > > I thought that module properties could be overridden per Group like > that (like qbs.installDir), but it seems I'm wrong here. When trying to > access them in the output Artifact of the module's rule (using > product.moduleProperty()) they are always undefined. You need to call moduleProperty() on the input artifact object in that case (inputs[tag][i].moduleProperty()). Christian From atelszewski at gmail.com Thu Aug 25 01:11:54 2016 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Thu, 25 Aug 2016 01:11:54 +0200 Subject: [QBS] Multiple products, sharing the same settings, within single .qbs file Message-ID: Hi, Is it possible to have multiple products, with common settings, in single qbs file? Say, something like: Project { Settings { cpp.warningLevel: "all" cpp.cxxLanguageVersion: "gnu99" } Product { SomehowReference: Settings name: "p1" files: "p1.c" } Product { SomehowReference: Settings name: "p2" files: "p2.c" } } I would love to have all of this in a single file. Thanks in advance! -- Best regards, Andrzej Telszewski From enmarantispam at gmail.com Thu Aug 25 01:17:21 2016 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Thu, 25 Aug 2016 02:17:21 +0300 Subject: [QBS] Multiple products, sharing the same settings, within single .qbs file In-Reply-To: References: Message-ID: Yes, you can. import CommonFile as Base Base{ name: "product 1" } Base{ name: "product 2" } etc.... On Thu, Aug 25, 2016 at 2:11 AM, Andrzej Telszewski wrote: > Hi, > > Is it possible to have multiple products, with common settings, in single > qbs file? > > Say, something like: > > Project { > Settings { > cpp.warningLevel: "all" > cpp.cxxLanguageVersion: "gnu99" > } > > Product { > SomehowReference: Settings > name: "p1" > files: "p1.c" > } > > Product { > SomehowReference: Settings > name: "p2" > files: "p2.c" > } > } > > I would love to have all of this in a single file. > > Thanks in advance! > > -- > Best regards, > Andrzej Telszewski > _______________________________________________ > QBS mailing list > QBS at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atelszewski at gmail.com Thu Aug 25 01:31:36 2016 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Thu, 25 Aug 2016 01:31:36 +0200 Subject: [QBS] Multiple products, sharing the same settings, within single .qbs file In-Reply-To: References: Message-ID: <90f2d02b-df97-c225-46c1-93de19ff8220@gmail.com> On 25/08/16 01:17, NIkolai Marchenko wrote: > Yes, you can. > > import CommonFile as Base > Base{ > name: "product 1" > } > Base{ > name: "product 2" > } > etc.... This: import CommonFile as Base gives me error: error: import CommonFile not found Unless by CommonFile you meant MY file with common settings? But if so, then I don't actually want that. I want both common settings and multiple products to be in *single* file. I'm using qbs 1.5.2 Thanks. > > On Thu, Aug 25, 2016 at 2:11 AM, Andrzej Telszewski > > wrote: > > Hi, > > Is it possible to have multiple products, with common settings, in > single qbs file? > > Say, something like: > > Project { > Settings { > cpp.warningLevel: "all" > cpp.cxxLanguageVersion: "gnu99" > } > > Product { > SomehowReference: Settings > name: "p1" > files: "p1.c" > } > > Product { > SomehowReference: Settings > name: "p2" > files: "p2.c" > } > } > > I would love to have all of this in a single file. > > Thanks in advance! > > -- > Best regards, > Andrzej Telszewski > _______________________________________________ > QBS mailing list > QBS at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs > > > -- Best regards, Andrzej Telszewski From enmarantispam at gmail.com Thu Aug 25 01:44:40 2016 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Thu, 25 Aug 2016 02:44:40 +0300 Subject: [QBS] Multiple products, sharing the same settings, within single .qbs file In-Reply-To: <90f2d02b-df97-c225-46c1-93de19ff8220@gmail.com> References: <90f2d02b-df97-c225-46c1-93de19ff8220@gmail.com> Message-ID: yes, I meant a separate settings file. I do not know if it is possible to do what you want in a single file. On Thu, Aug 25, 2016 at 2:31 AM, Andrzej Telszewski wrote: > On 25/08/16 01:17, NIkolai Marchenko wrote: > >> Yes, you can. >> >> import CommonFile as Base >> Base{ >> name: "product 1" >> } >> Base{ >> name: "product 2" >> } >> etc.... >> > > This: > import CommonFile as Base > > gives me error: > error: import CommonFile not found > > Unless by CommonFile you meant MY file with common settings? > But if so, then I don't actually want that. > > I want both common settings and multiple products to be in *single* file. > > I'm using qbs 1.5.2 > > Thanks. > > >> On Thu, Aug 25, 2016 at 2:11 AM, Andrzej Telszewski >> > wrote: >> >> Hi, >> >> Is it possible to have multiple products, with common settings, in >> single qbs file? >> >> Say, something like: >> >> Project { >> Settings { >> cpp.warningLevel: "all" >> cpp.cxxLanguageVersion: "gnu99" >> } >> >> Product { >> SomehowReference: Settings >> name: "p1" >> files: "p1.c" >> } >> >> Product { >> SomehowReference: Settings >> name: "p2" >> files: "p2.c" >> } >> } >> >> I would love to have all of this in a single file. >> >> Thanks in advance! >> >> -- >> Best regards, >> Andrzej Telszewski >> _______________________________________________ >> QBS mailing list >> QBS at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/qbs >> >> >> >> > > -- > Best regards, > Andrzej Telszewski > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atelszewski at gmail.com Thu Aug 25 03:08:33 2016 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Thu, 25 Aug 2016 03:08:33 +0200 Subject: [QBS] Multiple products, sharing the same settings, within single .qbs file In-Reply-To: References: <90f2d02b-df97-c225-46c1-93de19ff8220@gmail.com> Message-ID: On 25/08/16 01:44, NIkolai Marchenko wrote: > yes, I meant a separate settings file. I do not know if it is possible > to do what you want in a single file. > Oh, I see. I'll do it with separate file then. Thanks! > On Thu, Aug 25, 2016 at 2:31 AM, Andrzej Telszewski > > wrote: > > On 25/08/16 01:17, NIkolai Marchenko wrote: > > Yes, you can. > > import CommonFile as Base > Base{ > name: "product 1" > } > Base{ > name: "product 2" > } > etc.... > > > This: > import CommonFile as Base > > gives me error: > error: import CommonFile not found > > Unless by CommonFile you meant MY file with common settings? > But if so, then I don't actually want that. > > I want both common settings and multiple products to be in *single* > file. > > I'm using qbs 1.5.2 > > Thanks. > > > On Thu, Aug 25, 2016 at 2:11 AM, Andrzej Telszewski > > >> > wrote: > > Hi, > > Is it possible to have multiple products, with common > settings, in > single qbs file? > > Say, something like: > > Project { > Settings { > cpp.warningLevel: "all" > cpp.cxxLanguageVersion: "gnu99" > } > > Product { > SomehowReference: Settings > name: "p1" > files: "p1.c" > } > > Product { > SomehowReference: Settings > name: "p2" > files: "p2.c" > } > } > > I would love to have all of this in a single file. > > Thanks in advance! > > -- > Best regards, > Andrzej Telszewski > _______________________________________________ > QBS mailing list > QBS at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/qbs > > > > > > > > -- > Best regards, > Andrzej Telszewski > > -- Best regards, Andrzej Telszewski From christian.kandeler at qt.io Thu Aug 25 10:48:49 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 25 Aug 2016 10:48:49 +0200 Subject: [QBS] Multiple products, sharing the same settings, within single .qbs file In-Reply-To: References: Message-ID: <8342235c-d441-ebdf-d2b7-a722ebd94fc3@qt.io> On 08/25/2016 01:11 AM, Andrzej Telszewski wrote: > Is it possible to have multiple products, with common settings, in > single qbs file? > > Say, something like: > > Project { > Settings { > cpp.warningLevel: "all" > cpp.cxxLanguageVersion: "gnu99" > } > > Product { > SomehowReference: Settings > name: "p1" > files: "p1.c" > } > > Product { > SomehowReference: Settings > name: "p2" > files: "p2.c" > } > } > > I would love to have all of this in a single file. Project { Product { name: "settings" Export { Depends { name: "cpp" } cpp.warningLevel: "all" cpp.cxxLanguageVersion: "gnu99" } } Product { Depends { name: "settings" } name: "p1" files: "p1.c" } Product { Depends { name: "settings" } name: "p2" files: "p2.c" } } Christian From christian.kandeler at qt.io Thu Aug 25 15:13:02 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 25 Aug 2016 15:13:02 +0200 Subject: [QBS] qbs 1.6.0 released Message-ID: <05add5df-66c8-e6af-f607-df9453dc386a@qt.io> Hi, qbs 1.6.0 has been released today. The usual packages and a change log can be found at https://download.qt.io/official_releases/qbs/1.6.0. This version of qbs is also part of Qt Creator 4.1.0, which was released today as well. Christian From Jake.Petroules at qt.io Fri Aug 26 10:57:33 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 26 Aug 2016 08:57:33 +0000 Subject: [QBS] qbs 1.6.0 released In-Reply-To: <05add5df-66c8-e6af-f607-df9453dc386a@qt.io> References: <05add5df-66c8-e6af-f607-df9453dc386a@qt.io> Message-ID: As usual, qbs 1.6.0 is now available on: • Chocolatey (which is now a trusted package, so future updates should be faster!) • Homebrew • MacPorts • Arch -- an AUR is available (https://aur.archlinux.org/packages/qbs/); please vote for it to get it accepted into the mainline! • Fedora -- an official packaging is still in the works, but https://copr.fedoraproject.org/coprs/jakepetroules/qbs/ is available for convenience (unsupported) Older versions of qbs exist in Debian (testing, unstable) and Ubuntu (universe) beginning with Vivid (15.04). On Aug 25, 2016, at 6:13 AM, Christian Kandeler > wrote: Hi, qbs 1.6.0 has been released today. The usual packages and a change log can be found at https://download.qt.io/official_releases/qbs/1.6.0. This version of qbs is also part of Qt Creator 4.1.0, which was released today as well. Christian _______________________________________________ QBS mailing list QBS at qt-project.org http://lists.qt-project.org/mailman/listinfo/qbs -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From dorian.jicquel at mana-sys.fr Wed Aug 31 17:09:35 2016 From: dorian.jicquel at mana-sys.fr (Jicquel Dorian) Date: Wed, 31 Aug 2016 17:09:35 +0200 Subject: [QBS] Build issue with qbs ( Windows 7.1 sdk , Qt 5.2.1 , Qbs 1.6.0 ) Message-ID: <37cc2e3e-81b6-2473-eff7-1e561c4cac6e@mana-sys.fr> Hi, I'm currently trying to build a simple program using Qt 5.2.1 ( built with Windows 7 sdk v7.1.7600.0.30514 x86 ) and i found that qbs doesn't use the corresponding compiler ( cl.exe ) . More precisely it uses the VC10 compiler while analyzing the project ( not during build ) and then crashes as you can see in the output below : C:\QtEnterprise\Tools\QtCreator\share\qtcreator\qbs\share\qbs\imports\qbs\Probes\MsvcProbe.qbs:47: erreur : Error: Could not run C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/Bin/cl.exe (Le processus a planté) I checked the settings and everything seems fine and it worked before the 1.6 update so i assume it uses the wrong cl.exe file in the qbs source. Please find in attachments the files used to reproduce the error. Thanks in advance, Regards, Dorian. -------------- next part -------------- import qbs CppApplication { consoleApplication: true files: "main.cpp" Group { // Properties for the produced executable fileTagsFilter: product.type qbs.install: true } } -------------- next part -------------- #include using namespace std; int main(int argc, char *argv[]) { cout << "Hello World!" << endl; return 0; }