From christian.kandeler at qt.io Fri Dec 1 10:03:21 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 1 Dec 2017 10:03:21 +0100 Subject: [Qbs] How to set GCC optimization -O3 in releasebuilds? In-Reply-To: References: Message-ID: <20171201100321.32bb8bf4@ckandeler-archlinux> On Thu, 30 Nov 2017 23:45:51 +0100 Ola Røer Thorsen wrote: > what's the recommended way to configure qbs to build C++ code with GCC > using the -O3 optimizer level? I see it's using -O2 for the "fast" > qbs.optimization setting. In this case, do not set cpp.optimization and use cpp.cxxFlags directly. We've decided against allowing more values for cpp.optimization because of the difficulties to abstract away the differences between the platforms (see https://codereview.qt-project.org/#/c/183884/). > My intended workflow is to use -O3 when building from QtCreator in release > mode, while not having to set properties from the command line manually. > This is a somewhat large codebase with several static libraries and > applications (similar in structure as the Qt source tree), currently being > built using qmake. > > I might also want to add more default compiler flags "globally" > (-ffast-math etc) at some point. Is it best to create my own > "CustomStaticLibrary" and "CustomApplication"-items and make sure to use > those everywhere instead of the regular ones provided with Qbs? Inheritance is one possibility. Another one is a project-specific module. For instance: // /modules/myprojectsettings/myprojectsettings.qbs Module { // ... Properties { condition: qbs.buildVariant === "release" && qbs.toolchain.contains("gcc") cpp.cxxFlags: ["-ffast-math", "-O3"] } } // someproduct.qbs Product { // ... Depends { name: "myprojectsettings" } } Christian From ola at silentwings.no Fri Dec 1 12:12:16 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Fri, 1 Dec 2017 12:12:16 +0100 Subject: [Qbs] How to set GCC optimization -O3 in releasebuilds? In-Reply-To: <20171201100321.32bb8bf4@ckandeler-archlinux> References: <20171201100321.32bb8bf4@ckandeler-archlinux> Message-ID: 2017-12-01 10:03 GMT+01:00 Christian Kandeler : > > In this case, do not set cpp.optimization and use cpp.cxxFlags directly. > We've decided against allowing more values for cpp.optimization because of > the difficulties to abstract away the differences between the platforms > (see https://codereview.qt-project.org/#/c/183884/). > > Makes sense. > Inheritance is one possibility. Another one is a project-specific module. > For instance: > > // /modules/myprojectsettings/myprojectsettings.qbs > Module { > // ... > Properties { > condition: qbs.buildVariant === "release" && > qbs.toolchain.contains("gcc") > cpp.cxxFlags: ["-ffast-math", "-O3"] > } > } > > // someproduct.qbs > Product { > // ... > Depends { name: "myprojectsettings" } > } > > I quite like the module-solution. I'll have to include the Depends-item in every product file, right? Thanks! Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Fri Dec 1 12:36:54 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 1 Dec 2017 12:36:54 +0100 Subject: [Qbs] How to set GCC optimization -O3 in releasebuilds? In-Reply-To: References: <20171201100321.32bb8bf4@ckandeler-archlinux> Message-ID: <20171201123654.7823da61@ckandeler-archlinux> On Fri, 1 Dec 2017 12:12:16 +0100 Ola Røer Thorsen wrote: > 2017-12-01 10:03 GMT+01:00 Christian Kandeler : > > Inheritance is one possibility. Another one is a project-specific module. > > For instance: > > > > // /modules/myprojectsettings/myprojectsettings.qbs > > Module { > > // ... > > Properties { > > condition: qbs.buildVariant === "release" && > > qbs.toolchain.contains("gcc") > > cpp.cxxFlags: ["-ffast-math", "-O3"] > > } > > } > > > > // someproduct.qbs > > Product { > > // ... > > Depends { name: "myprojectsettings" } > > } > > > > > I quite like the module-solution. I'll have to include the Depends-item in > every product file, right? Yes, but you can combine this with inheritance and add the dependency in the base item. The advantage to a purely inheritance-based approach is that you can have different base items that share these settings without duplication (except for the dependency on the module). Christian From Jake.Petroules at qt.io Sat Dec 2 23:03:39 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sat, 2 Dec 2017 22:03:39 +0000 Subject: [Qbs] qbs questions In-Reply-To: <085b4968-469d-aec2-f3bf-f39d66846f6e@gmail.com> References: <085b4968-469d-aec2-f3bf-f39d66846f6e@gmail.com> Message-ID: <74FA8562-0447-4D7A-8583-585185181B99@qt.io> Hi Carlos, In future please try to direct questions to the Qbs mailing list so all can benefit from and help to answer questions. :) In Qbs, almost everything is also a "variable", or in Qbs parlance, a module property. You can override these properties on the command line when running a Qbs project. https://doc-snapshots.qt.io/qbs/building-applications.html contains some examples of this. We also have specific functionality for running tools like static analyzers, ccache, etc., which you can handle by setting the cpp.compilerWrapper property; the values in this property will be prepended to the compiler command line. See http://doc-snapshots.qt.io/qbs/cpp-module.html for documentation on this property. There's also the generators functionality, where you can write plugins in C++ that allow you to traverse the Qbs build graph as it is executed. This allows things like generating Clang compilation databases. See https://doc-snapshots.qt.io/qbs/generators.html#generating-clang-compilation-databases So yes, we have plenty of functionality for doing these sorts of things and we'd always love to hear more specific use cases so we can make Qbs flexible enough to cover everyone's needs as much as feasible. Cheers! > On Dec 2, 2017, at 12:20 PM, Carlos Mazieri wrote: > > Hello Jake > > I have few questions regarding QBS, > > What I like in "qmake" is that almost everything is a variable, SOURCES, HEADERS, we can set different compiler versions by setting QMAKE_CXX, etc. > > I am the author of a simple project called QtProjectTool which is pipe for Qmake Qt projects to other command line tools, it integrates command line tools such as "cppcheck", "cpplint" among others in QtCreator acting as an external plugin. > The QtProjectTool project does not parse qmake project files, instead of this it adds some functions to the project file in order to print the content of some variables using "message()" function, then it runs "qmake" and parse its output to get the SOURCES, HEADERS, DEFINES, INCLUDEPATH among other information. > > > Does "QBS" provide a way to other applications extract that kind of information from QBS project files? > > > I am looking forward to enhancing QtProjectTool in order to support "QBS" projects as well. > > Thanks in advance, > > Carlos J. Mazieri > > > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From chgans at gmail.com Sun Dec 3 08:27:34 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Sun, 3 Dec 2017 20:27:34 +1300 Subject: [Qbs] Dependencies on internal products using 'submodules' Message-ID: Hi there, I would like to know if it's possible to list internal product dependencies using the 'submodules' syntax, eg: MyProduct { name: "foo" files: [ ... ] Depends { name: "Qt" submodules: [ ... ] } Depends { name: "LibrarySubProject" submodules: [ // <===== "lib1", "lib2" ] } } Where "LibrarySubProject" is an inline sub-project in the root project and lib1, lib2 are internal library products referenced by "SubProject". This is different from my "third party" modules defined in $qbsSearchPath/modules/ThirdParty/..." I know I can use the Depends { name: "lib1" } form, but for "cosmetic" reasons, I would like to use the 'submodules' approach. You might think that i'm a bit picky, but using this syntax, it makes the product.qbs easy to read, pleasant *and* easy to understand. That could help me to convince people while show-casing qbs. I could write one module per library in $qbsSearchPath/modules/ but that would be redundant and a bit awkward to maintain. Chris From Jake.Petroules at qt.io Sun Dec 3 08:40:17 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sun, 3 Dec 2017 07:40:17 +0000 Subject: [Qbs] Dependencies on internal products using 'submodules' In-Reply-To: References: Message-ID: <722468D1-E652-4F05-B3FF-D9065CA1EA73@qt.io> Qbs has a global view of the entire project, so there's no need to qualify the names of your lib1, lib2 dependencies with the name of the sub-project in which they're defined. I think your idea of a cleaner syntax could be something of the form: Depends { names: ["lib1", "lib2"] } Basically, a condensed syntax that would allow to specify multiple dependency names in a single depends item, and optionally apply additional properties to all of those, like so: Depends { names: ["lib1", "lib2"]; condition: project.hasCoolLibs } equivalent to: Depends { name: "lib1"; condition: project.hasCoolLibs } Depends { name: "lib2"; condition: project.hasCoolLibs } A "names" property as such would be mutually exclusive with the existing submodules and productTypes property, as well as the name property. However your proposal as-is cannot work as the name of a dependency must be the name of a product or module, and projects have nothing to do with this. I don't think trying to add them into the mix would make any sense, but I think something what I suggested above would effectively solve the same problem I believe you're looking to do so, which is to remove redundant syntax (and my proposal requires fewer characters too :D). > On Dec 2, 2017, at 11:27 PM, Christian Gagneraud wrote: > > Hi there, > > I would like to know if it's possible to list internal product dependencies using the 'submodules' syntax, eg: > > MyProduct { > name: "foo" > files: [ > ... > ] > Depends { > name: "Qt" > submodules: [ > ... > ] > } > Depends { > name: "LibrarySubProject" > submodules: [ // <===== > "lib1", > "lib2" > ] > } > } > > Where "LibrarySubProject" is an inline sub-project in the root project and lib1, lib2 are internal library products referenced by "SubProject". > This is different from my "third party" modules defined in $qbsSearchPath/modules/ThirdParty/..." > > > I know I can use the Depends { name: "lib1" } form, but for "cosmetic" reasons, I would like to use the 'submodules' approach. > > You might think that i'm a bit picky, but using this syntax, it makes the product.qbs easy to read, pleasant *and* easy to understand. > That could help me to convince people while show-casing qbs. > > I could write one module per library in $qbsSearchPath/modules/ but that would be redundant and a bit awkward to maintain. > > > Chris > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From chgans at gmail.com Sun Dec 3 19:05:57 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Mon, 4 Dec 2017 07:05:57 +1300 Subject: [Qbs] Dependencies on internal products using 'submodules' In-Reply-To: <722468D1-E652-4F05-B3FF-D9065CA1EA73@qt.io> References: <722468D1-E652-4F05-B3FF-D9065CA1EA73@qt.io> Message-ID: On 03/12/17 20:40, Jake Petroules wrote: > Qbs has a global view of the entire project, so there's no need to > qualify the names of your lib1, lib2 dependencies with the name of > the sub-project in which they're defined. I think your idea of a > cleaner syntax could be something of the form: > > Depends { names: ["lib1", "lib2"] } > > Basically, a condensed syntax that would allow to specify multiple > dependency names in a single depends item, and optionally apply > additional properties to all of those, like so: > > Depends { names: ["lib1", "lib2"]; condition: project.hasCoolLibs } > > equivalent to: > > Depends { name: "lib1"; condition: project.hasCoolLibs } Depends { > name: "lib2"; condition: project.hasCoolLibs } > > A "names" property as such would be mutually exclusive with the > existing submodules and productTypes property, as well as the name > property. > > However your proposal as-is cannot work as the name of a dependency > must be the name of a product or module, and projects have nothing to > do with this. I don't think trying to add them into the mix would > make any sense, but I think something what I suggested above would > effectively solve the same problem I believe you're looking to do so, > which is to remove redundant syntax (and my proposal requires fewer > characters too :D). Hi Jakes, Yes, I sort of knew that project/products have nothing to do with modules (I don't know why, but i've read something about it). I like your proposition, it's IMHO a good compromise. On the other hand you say that "there is no need to qualify a dependency with the name of the project where it is declared", and it seems to justify why this is not supported. "Not necessary" doesn't always imply "not possible". After all there's already similar mechanism with limitToSubProject (Depends/Project coupling), so why not allowing an optional syntax, where name refers to a project, and submodules refer to products from this project. Or maybe in that case, a "project" property could be use in place of "name" (that would make the Depends item syntax a bit messy tho). One (wild mind ;)) could imagine something like: Depends { project: "MyLibraries" products: [ "lib1", ... ] } I don't know the internals of Qbs, so please excuse me if the above doesn't make sense to you. This is not a show stopper for me, just a nice to have. IMHO it keeps the product.qbs tidy, and is in sync with the concept that you write code once, but it gets read countless time, so it's good to make it easy to read/understand. Is it worth creating a proposal/use-case ticket based on this thread? Chris From Jake.Petroules at qt.io Sun Dec 3 20:06:12 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sun, 3 Dec 2017 19:06:12 +0000 Subject: [Qbs] Dependencies on internal products using 'submodules' In-Reply-To: References: <722468D1-E652-4F05-B3FF-D9065CA1EA73@qt.io> Message-ID: > On Dec 3, 2017, at 10:05 AM, Christian Gagneraud wrote: > > On 03/12/17 20:40, Jake Petroules wrote: >> Qbs has a global view of the entire project, so there's no need to >> qualify the names of your lib1, lib2 dependencies with the name of >> the sub-project in which they're defined. I think your idea of a >> cleaner syntax could be something of the form: >> Depends { names: ["lib1", "lib2"] } >> Basically, a condensed syntax that would allow to specify multiple >> dependency names in a single depends item, and optionally apply >> additional properties to all of those, like so: >> Depends { names: ["lib1", "lib2"]; condition: project.hasCoolLibs } >> equivalent to: >> Depends { name: "lib1"; condition: project.hasCoolLibs } Depends { >> name: "lib2"; condition: project.hasCoolLibs } >> A "names" property as such would be mutually exclusive with the >> existing submodules and productTypes property, as well as the name >> property. >> However your proposal as-is cannot work as the name of a dependency >> must be the name of a product or module, and projects have nothing to >> do with this. I don't think trying to add them into the mix would >> make any sense, but I think something what I suggested above would >> effectively solve the same problem I believe you're looking to do so, >> which is to remove redundant syntax (and my proposal requires fewer >> characters too :D). > > Hi Jakes, > > Yes, I sort of knew that project/products have nothing to do with modules (I don't know why, but i've read something about it). > > I like your proposition, it's IMHO a good compromise. > > On the other hand you say that "there is no need to qualify a dependency with the name of the project where it is declared", and it seems to justify why this is not supported. "Not necessary" doesn't always imply "not possible". After all there's already similar mechanism with limitToSubProject (Depends/Project coupling), so why not allowing an optional syntax, where name refers to a project, and submodules refer to products from this project. Or maybe in that case, a "project" property could be use in place of "name" (that would make the Depends item syntax a bit messy tho). One (wild mind ;)) could imagine something like: > > Depends { > project: "MyLibraries" > products: [ > "lib1", > ... > ] > } > > I don't know the internals of Qbs, so please excuse me if the above doesn't make sense to you. My point was that product names are already required to be globally unique across your project (and all sub-projects), so qualifying with the name of a sub-project wouldn't do anything. > > This is not a show stopper for me, just a nice to have. IMHO it keeps the product.qbs tidy, and is in sync with the concept that you write code once, but it gets read countless time, so it's good to make it easy to read/understand. > > Is it worth creating a proposal/use-case ticket based on this thread? Of course, feel free. > > Chris -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From synasius at gmail.com Tue Dec 5 09:51:51 2017 From: synasius at gmail.com (Federico Frenguelli) Date: Tue, 5 Dec 2017 09:51:51 +0100 Subject: [Qbs] Is it possible to include Qt libraries in InstallPackage output archive? Message-ID: Hi, I have a big application that I recently ported to QBS. I have a tons of legacy bash scripts that produce a .tar.gz archive which includes the Qt dynamic libraries (like libQtCore5Core.so.5 etc..) so that our users can just unpack and run the app. Is it possible to achieve the same in QBS using the InstallPackage item (docs: http://doc.qt.io/qbs/installpackage-item.html)? Are there other ways to do that? -- Federico Frenguelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Tue Dec 5 10:18:44 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 5 Dec 2017 09:18:44 +0000 Subject: [Qbs] Is it possible to include Qt libraries in InstallPackage output archive? In-Reply-To: References: Message-ID: <32B8C849-9076-4F48-AB22-5FFF71956D69@qt.io> Deployment of third party libraries is still under development. There are some workarounds you can use for now, though. See here for inspiration: https://codereview.qt-project.org/#/c/213299/ > On Dec 5, 2017, at 12:51 AM, Federico Frenguelli wrote: > > Hi, > > I have a big application that I recently ported to QBS. > I have a tons of legacy bash scripts that produce a .tar.gz archive which includes the Qt dynamic libraries (like libQtCore5Core.so.5 etc..) so that our users can just unpack and run the app. > > Is it possible to achieve the same in QBS using the InstallPackage item (docs: http://doc.qt.io/qbs/installpackage-item.html)? > Are there other ways to do that? > > > -- > Federico Frenguelli > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From synasius at gmail.com Tue Dec 5 14:54:01 2017 From: synasius at gmail.com (Federico Frenguelli) Date: Tue, 5 Dec 2017 14:54:01 +0100 Subject: [Qbs] Is it possible to include Qt libraries in InstallPackage output archive? In-Reply-To: <32B8C849-9076-4F48-AB22-5FFF71956D69@qt.io> References: <32B8C849-9076-4F48-AB22-5FFF71956D69@qt.io> Message-ID: Thanks Jake, I'll take a look to the code you linked! I'm glad to hear that this feature is under development. On 5 December 2017 at 10:18, Jake Petroules wrote: > Deployment of third party libraries is still under development. There are > some workarounds you can use for now, though. See here for inspiration: > > https://codereview.qt-project.org/#/c/213299/ > > > On Dec 5, 2017, at 12:51 AM, Federico Frenguelli > wrote: > > > > Hi, > > > > I have a big application that I recently ported to QBS. > > I have a tons of legacy bash scripts that produce a .tar.gz archive > which includes the Qt dynamic libraries (like libQtCore5Core.so.5 etc..) so > that our users can just unpack and run the app. > > > > Is it possible to achieve the same in QBS using the InstallPackage item > (docs: http://doc.qt.io/qbs/installpackage-item.html)? > > Are there other ways to do that? > > > > > > -- > > Federico Frenguelli > > _______________________________________________ > > Qbs mailing list > > Qbs at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/qbs > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > -- Federico Frenguelli -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Tue Dec 5 16:47:05 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 5 Dec 2017 18:47:05 +0300 Subject: [Qbs] Is it possible to include Qt libraries in InstallPackage output archive? In-Reply-To: References: <32B8C849-9076-4F48-AB22-5FFF71956D69@qt.io> Message-ID: Hi Federico, You can take the 'hack' from the qbs sources, where are used a custom rule with windeployqt utility. e.g. look on qbs\src\packages\archive\archive.qbs. You can try to expand it himself to using of macdeployqt && lindeployqt (custom). BR, Denis 05.12.2017 16:54, Federico Frenguelli пишет: > Thanks Jake, > I'll take a look to the code you linked! > > I'm glad to hear that this feature is under development. > > > > > On 5 December 2017 at 10:18, Jake Petroules > wrote: > > Deployment of third party libraries is still under development. > There are some workarounds you can use for now, though. See here > for inspiration: > > https://codereview.qt-project.org/#/c/213299/ > > > > On Dec 5, 2017, at 12:51 AM, Federico Frenguelli > > wrote: > > > > Hi, > > > > I have a big application that I recently ported to QBS. > > I have a tons of legacy bash scripts that produce a .tar.gz > archive which includes the Qt dynamic libraries (like > libQtCore5Core.so.5 etc..) so that our users can just unpack and > run the app. > > > > Is it possible to achieve the same in QBS using the > InstallPackage item (docs: > http://doc.qt.io/qbs/installpackage-item.html > )? > > Are there other ways to do that? > > > > > > -- > > Federico Frenguelli > > _______________________________________________ > > Qbs mailing list > > Qbs at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/qbs > > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > > > > -- > Federico Frenguelli > > > _______________________________________________ > 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 ola at silentwings.no Thu Dec 7 22:38:56 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Thu, 7 Dec 2017 22:38:56 +0100 Subject: [Qbs] How do I build using GCC with the "-march=native" option? Message-ID: Hi, I'm trying to build my code with the gcc "-march=native"-option (x86-64), or any other value there for that matter. Qbs won't let me do that using cpp.cxxFlags: [ "-march=native" ] saying "warning: The following properties have invalid values: cpp.cxxFlags: '-target', '-triple', '-arch' and '-march' cannot appear in flags; set qbs.architecture instead" Trying qbs.architecture: "native" gives "warning: The following properties have invalid values: cpp.architecture: 'native' differs from the architecture produced by this compiler (x86_64)" How do I fix this? The -mtune option works but it's not quite what I'm after here. Best regards, Ola Røer Thorsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Fri Dec 8 11:17:29 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 8 Dec 2017 11:17:29 +0100 Subject: [Qbs] How do I build using GCC with the "-march=native" option? In-Reply-To: References: Message-ID: <20171208111729.6d732833@ckandeler-archlinux> On Thu, 7 Dec 2017 22:38:56 +0100 Ola Røer Thorsen wrote: > Hi, I'm trying to build my code with the gcc "-march=native"-option > (x86-64), or any other value there for that matter. Qbs won't let me do > that using > > cpp.cxxFlags: [ "-march=native" ] > > saying > > "warning: The following properties have invalid values: > cpp.cxxFlags: '-target', '-triple', '-arch' and '-march' cannot appear in > flags; set qbs.architecture instead" I believe qbs is being overly strict here. There seem to be legitimate use cases for -march not covered by dedicated properties. See also https://bugreports.qt.io/browse/QBS-1018. > qbs.architecture: "native" > > gives > > "warning: The following properties have invalid values: > cpp.architecture: 'native' differs from the architecture produced by this > compiler (x86_64)" > > How do I fix this? As a workaround, you can try the (undocumented) cpp.machineType property. It doesn't do anything when using clang, though. Christian From ola at silentwings.no Fri Dec 8 11:28:00 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Fri, 8 Dec 2017 11:28:00 +0100 Subject: [Qbs] How do I build using GCC with the "-march=native" option? In-Reply-To: <20171208111729.6d732833@ckandeler-archlinux> References: <20171208111729.6d732833@ckandeler-archlinux> Message-ID: 2017-12-08 11:17 GMT+01:00 Christian Kandeler : > > I believe qbs is being overly strict here. There seem to be legitimate > use cases for -march not covered by dedicated properties. See also > https://bugreports.qt.io/browse/QBS-1018. > > Ah, I missed that bugreport. Yes I'd agree it's being too strict with regards to -march. Would be nice if this was fixed. My use case is to run some computational code as fast as possible on the host machine, so I'd like the best optimization possible. > > As a workaround, you can try the (undocumented) cpp.machineType property. > It doesn't do anything when using clang, though. > I'll try that for now. Thanks! Best regards, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Fri Dec 8 13:27:41 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 8 Dec 2017 13:27:41 +0100 Subject: [Qbs] qbs 1.10 released Message-ID: <20171208132741.11ed433b@ckandeler-archlinux> Hello, we have released qbs 1.10 today. Find all the relevant information in the blog post at http://blog.qt.io/blog/2017/12/07/qbs-1-10-released/. Christian From Jake.Petroules at qt.io Fri Dec 8 17:45:40 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 8 Dec 2017 16:45:40 +0000 Subject: [Qbs] URGENT: Broken qbs package version in Fedora Rawhide In-Reply-To: References: <21D40D8D-1295-448A-A03D-80121DD7F77B@qt.io> <83968771-2818-7aaf-356d-68115010d817@gmail.com> <440757d1-d122-1e2c-5eb1-3de6d8e6d95f@gmail.com> <6848B807-7654-4A8F-9D37-6C48218A43AA@qt.io> <05EDDFDD-2999-4AC6-88DF-8C5E588B91A1@qt.io> <0e19bec4-6e74-9931-8b3e-783715761a8a@gmail.com> <6D7BC825-F681-4241-8CDB-992501BF81B9@qt.io> <6cee4a99-f079-76bd-734c-59eb03bc26e5@gmail.com> <38cc77f1-f1f6-2184-4a8f-6f4ec739de12@gmail.com> <2E13678B-444E-4316-B5BE-2E7B855A21BA@qt.io> <5b7b247e-d588-9695-a813-9c6d9b23b70e@gmail.com> Message-ID: <9E67C817-6CC4-4DE3-8D77-2B8524F1CCB2@qt.io> You need to set the autotest profile. Set the QBS_AUTOTEST_PROFILE environment variable to the name of the profile generated by qbs-setup-qt. See https://anonscm.debian.org/cgit/pkg-kde/qt/qbs.git/tree/debian/rules for guidance. Note that they simply create a qbs_autotests profile; Qbs no longer hardcodes that profile name, you need to set QBS_AUTOTEST_PROFILE in order to let it find it. Also, please send future inquiries to the Qbs public mailing list. Thanks! > On Dec 8, 2017, at 6:13 AM, Sandro Mani wrote: > > Hi Jake > > Since you've kindly helped me in the past with the qbs packaging, I wonder if you could help me with the following issue: I'm updating qbs to 1.10 on Fedora, and am hitting test failures when running tst_api which I suppose are down to some configuration issue but I can't figure out what's missing. I used to run the tests as follows: > > export LD_LIBRARY_PATH=%{buildroot}%{_libdir} > %{buildroot}/%{_bindir}/%{name} setup-qt %{_bindir}/qmake-qt5 qt > %{buildroot}/%{_bindir}/%{name} config profiles.qbs_autotests.baseProfile qt > make check > > which though results in many failures like > > FAIL! : TestApi::addQObjectMacroToCppFile() '!errorInfo.hasError()' returned FALSE. (/home/sandro/rpmbuild/BUILD/qbs-src-1.10.0/share/qbs/imports/qbs/base/QtApplication.qbs:34:5 Dependency 'Qt.core' not found for product 'add-qobject-macro-to-cpp-file'. > Please create a Qt profile using the qbs-setup-qt tool if you haven't already done so.) > Loc: [tst_api.cpp(176)] > > Digging a bit I discovered the qbs-setup-toolchains and qbs-setup-qt commands, so I changed the test setup to > > export LD_LIBRARY_PATH=%{buildroot}%{_libdir} > %{buildroot}/%{_bindir}/qbs-setup-toolchains --detect > %{buildroot}/%{_bindir}/qbs-setup-qt --detect > make check > > but I still get the failures above. Any ideas? FWIW, the full build spec is attached. > > (Also attached is a patch I need to get the blackbox lexyacc test to pass, without it fails due to "error: ‘yylval’ undeclared".) > > Thanks > Sandro > > On 01.08.2017 00:49, Sandro Mani wrote: >> Hi Jake >> >> Uhm not sure if I formulated my question correctly: I currently have the qbs-1.8.1 package we discussed. I now wanted to update to the qt-creator-4.4.0-beta1 (we have always updated to the latest version, even pre-release, in the Fedora master branch aka rawhide). But the problem is that qt-creator-4.4.0-beta1 cannot be built against qbs-1.8.1, it requires what will become 1.9.0. So I was just wondering whether separate qbs releases were planned matching what the latest qt-creator release requires. If not, no problem, I'll just package the git snapshot required. >> >> Thanks >> Sandro >> >> >> On 01.08.2017 00:44, Jake Petroules wrote: >>> Hi Sandro, >>> >>> Tagged releases of Qt Creator will always depend on tagged releases of Qbs. We currently have no plans to do beta releases of Qbs, but might in the future. >>> >>> As a Linux packager, you should for the most part completely ignore the submodule. Pretend it doesn't exist. >>> >>> If you're talking about a separate qt-creator-git package of sorts (separate from the main qbs and qt-creator packages), then I'm afraid I have no specific advice for you. >>> >>>> On Jul 31, 2017, at 1:44 PM, Sandro Mani wrote: >>>> >>>> Hi Jake >>>> >>>> I was just looking at updating to qt-creator-4.4.0-beta1 and build it against the separate qbs package, and noticed that qt-creator bundles (and depends on) an unreleased qbs snapshot. I can clearly easily just package the latest git snapshot of qbs, but taking git snapshots is always a bit risky. Ideally development versions of qbs would be released in parallel with qt-creator. Are there any plans to do this? Or how would you recommend dealing with this situation? >>>> >>>> Thanks >>>> Sandro >>>> >>>> >>>> On 31.07.2017 12:52, Sandro Mani wrote: >>>>> Hi Jake >>>>> >>>>> With the patch now I get a failure + timeout, see below. Any ideas? >>>>> >>>>> Thanks >>>>> Sandro >>>>> >>>>> >>>>> ********* Start testing of TestBlackbox ********* >>>>> Config: Using QtTest library 5.9.1, Qt 5.9.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 7.1.1 20170718 (Red Hat 7.1.1-6)) >>>>> PASS : TestBlackbox::initTestCase() >>>>> PASS : TestBlackbox::alwaysRun(Transformer) >>>>> FAIL! : TestBlackbox::alwaysRun(Rule) Compared values are not the same >>>>> Actual (runQbs(params)): 1 >>>>> Expected (0) : 0 >>>>> Loc: [tst_blackbox.cpp(308)] >>>>> >>>>> ========= Received signal, dumping stack ============== >>>>> GNU gdb (GDB) Fedora 8.0-17.fc27 >>>>> Copyright (C) 2017 Free Software Foundation, Inc. >>>>> License GPLv3+: GNU GPL version 3 or later >>>>> This is free software: you are free to change and redistribute it. >>>>> There is NO WARRANTY, to the extent permitted by law. Type "show copying" >>>>> and "show warranty" for details. >>>>> This GDB was configured as "x86_64-redhat-linux-gnu". >>>>> Type "show configuration" for configuration details. >>>>> For bug reporting instructions, please see: >>>>> . >>>>> Find the GDB manual and other documentation resources online at: >>>>> . >>>>> For help, type "help". >>>>> Type "apropos word" to search for commands related to "word". >>>>> Attaching to process 18640 >>>>> [New LWP 18642] >>>>> [Thread debugging using libthread_db enabled] >>>>> Using host libthread_db library "/usr/lib64/libthread_db.so.1". >>>>> 0x00007f1b410a6e66 in ppoll () from /usr/lib64/libc.so.6 >>>>> Missing separate debuginfos, use: dnf debuginfo-install bzip2-libs-1.0.6-22.fc26.x86_64 freetype-2.8-3.fc27.x86_64 glib2-2.53.4-2.fc27.x86_64 glibc-2.25.90-29.fc27.x86_64 graphite2-1.3.10-1.fc27.x86_64 harfbuzz-1.4.7-1.fc27.x86_64 libX11-1.6.5-2.fc27.x86_64 libXau-1.0.8-7.fc26.x86_64 libXext-1.3.3-5.fc26.x86_64 libgcc-7.1.1-6.fc27.x86_64 libgcrypt-1.7.8-1.fc27.x86_64 libglvnd-0.2.999-20.20170620gitd850cdd.fc27.x86_64 libglvnd-glx-0.2.999-20.20170620gitd850cdd.fc27.x86_64 libgpg-error-1.27-1.fc27.x86_64 libicu-57.1-4.fc26.x86_64 libpng-1.6.29-1.fc27.x86_64 libselinux-2.6-8.fc27.x86_64 libstdc++-7.1.1-6.fc27.x86_64 libxcb-1.12-3.fc26.x86_64 lz4-libs-1.7.5-4.fc27.x86_64 openssl-libs-1.1.0f-7.fc27.x86_64 pcre-8.41-1.fc27.x86_64 pcre2-utf16-10.30-0.3.RC1.fc27.x86_64 qt5-qtbase-5.9.1-3.fc27.x86_64 qt5-qtbase-gui-5.9.1-3.fc27.x86_64 qt5-qtscript-5.9.1-1.fc27.x86_64 systemd-libs-234-3.fc27.x86_64 xz-libs-5.2.3-2.fc26.x86_64 zlib-1.2.11-2.fc26.x86_64 >>>>> (gdb) >>>>> Thread 2 (Thread 0x7f1b3964d700 (LWP 18642)): >>>>> #0 0x00007f1b41076d77 in waitpid () from /usr/lib64/libc.so.6 >>>>> No symbol table info available. >>>>> #1 0x00007f1b40fe08e7 in do_system () from /usr/lib64/libc.so.6 >>>>> No symbol table info available. >>>>> #2 0x00007f1b4224a7e1 in stackTrace() [clone .part.2] () from /usr/lib64/libQt5Test.so.5 >>>>> No symbol table info available. >>>>> #3 0x00007f1b4224a86d in stackTrace() () from /usr/lib64/libQt5Test.so.5 >>>>> No symbol table info available. >>>>> #4 0x00007f1b422533bb in QTest::WatchDog::run() () from /usr/lib64/libQt5Test.so.5 >>>>> No symbol table info available. >>>>> #5 0x00007f1b419c746e in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5 >>>>> No symbol table info available. >>>>> #6 0x00007f1b3fb92609 in start_thread () from /usr/lib64/libpthread.so.0 >>>>> No symbol table info available. >>>>> #7 0x00007f1b410b337f in clone () from /usr/lib64/libc.so.6 >>>>> No symbol table info available. >>>>> >>>>> Thread 1 (Thread 0x7f1b42b6e8c0 (LWP 18640)): >>>>> #0 0x00007f1b410a6e66 in ppoll () from /usr/lib64/libc.so.6 >>>>> No symbol table info available. >>>>> #1 0x00007f1b41bf1d00 in qt_safe_poll(pollfd*, unsigned long, timespec const*) () from /usr/lib64/libQt5Core.so.5 >>>>> No symbol table info available. >>>>> #2 0x00007f1b41b2c0f8 in QProcessPrivate::waitForFinished(int) () from /usr/lib64/libQt5Core.so.5 >>>>> No symbol table info available. >>>>> #3 0x00007f1b41b2240d in QProcess::waitForFinished(int) () from /usr/lib64/libQt5Core.so.5 >>>>> No symbol table info available. >>>>> #4 0x000055902b20b305 in TestBlackboxBase::runQbs (this=0x7ffe51c12b20, params=...) at tst_blackboxbase.cpp:87 >>>>> args = {> = {> = {}, {p = {static shared_null = {ref = {atomic = { >>>>> _q_value = {> = {static _S_alignment = 4, _M_i = -1}, }}}, alloc = 0, begin = 0, end = 0, >>>>> array = {0x0}}, d = 0x55902bd21f70}, d = 0x55902bd21f70}}, } >>>>> process = >>>>> waitTime = 600000 >>>>> #5 0x000055902b1f372c in TestBlackbox::artifactScanning (this=0x7ffe51c12b20) at tst_blackbox.cpp:340 >>>>> projectDir = {static null = {}, d = 0x55902bd1ec20} >>>>> params = {command = {static null = {}, d = 0x55902bd37020}, >>>>> arguments = {> = {> = {}, {p = {static shared_null = {ref = {atomic = { >>>>> _q_value = {> = {static _S_alignment = 4, _M_i = -1}, }}}, alloc = 0, begin = 0, >>>>> end = 0, array = {0x0}}, d = 0x7f1b41c49300 }, >>>>> d = 0x7f1b41c49300 }}, }, buildDirectory = {static null = {}, >>>>> d = 0x7f1b41c46d00 }, environment = {d = {d = 0x55902bd24830}}, expectFailure = false, useProfile = true} >>>>> #6 0x00007f1b41bb0446 in QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument) const () >>>>> from /usr/lib64/libQt5Core.so.5 >>>>> No symbol table info available. >>>>> #7 0x00007f1b422513ba in QTest::TestMethods::invokeTestOnData(int) const () from /usr/lib64/libQt5Test.so.5 >>>>> No symbol table info available. >>>>> #8 0x00007f1b422520c0 in QTest::TestMethods::invokeTest(int, char const*, QTest::WatchDog*) const () from /usr/lib64/libQt5Test.so.5 >>>>> No symbol table info available. >>>>> #9 0x00007f1b422525f1 in QTest::TestMethods::invokeTests(QObject*) const () from /usr/lib64/libQt5Test.so.5 >>>>> No symbol table info available. >>>>> #10 0x00007f1b42252bab in QTest::qExec(QObject*, int, char**) () from /usr/lib64/libQt5Test.so.5 >>>>> No symbol table info available. >>>>> #11 0x000055902b1bf807 in main (argc=, argv=0x7ffe51c12c68) at tst_blackbox.cpp:4874 >>>>> app = >>>>> tc = { = { = {}, static staticMetaObject = {d = { >>>>> superdata = 0x7f1b41ff2ba0 , stringdata = 0x55902b21fd80 , >>>>> data = 0x55902b21fd20 , >>>>> static_metacall = 0x55902b20f5b0 , >>>>> relatedMetaObjects = 0x0, extradata = 0x0}}, testDataDir = {static null = {}, d = 0x55902bd16db0}, testSourceDir = { >>>>> static null = {}, d = 0x55902bd16d00}, qbsExecutableFilePath = {static null = {}, d = 0x55902bd16200}, >>>>> defaultInstallRoot = {static null = {}, d = 0x55902bd14970}, m_qbsStderr = {d = 0x55902bd25430}, m_qbsStdout = { >>>>> d = 0x55902bd254c0}}, static staticMetaObject = {d = {superdata = 0x55902b42b480 , >>>>> stringdata = 0x55902b21e000 , data = 0x55902b21cf00 , >>>>> static_metacall = 0x55902b20f170 , relatedMetaObjects = 0x0, >>>>> extradata = 0x0}}} >>>>> Detaching from program: /home/sandro/rpmbuild/BUILD/qbs-src-1.8.1/bin/tst_blackbox, process 18640 >>>>> ========= End of stack trace ============== >>>>> QFATAL : TestBlackbox::artifactScanning() Test function timed out >>>>> FAIL! : TestBlackbox::artifactScanning() Received a fatal error. >>>>> Loc: [Unknown file(0)] >>>>> Totals: 2 passed, 2 failed, 0 skipped, 0 blacklisted, 300834ms >>>>> ********* Finished testing of TestBlackbox ********* >>>>> >> > > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From hkarel at yandex.ru Sat Dec 9 15:00:34 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Sat, 9 Dec 2017 17:00:34 +0300 Subject: [Qbs] Linking dynamic library with version Message-ID: <1a3bda84-363d-b82e-191c-ce3761bbed59@yandex.ru> Hi, I need to connect the dynamic library 'soxr' to the QBS project. The system has a symlink of libsoxr.so.0 (with the version), but not libsoxr.so How can I connect to the project libsoxr.so.0? -- BR, Pavel Karelin -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Mon Dec 11 10:06:15 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 11 Dec 2017 10:06:15 +0100 Subject: [Qbs] Linking dynamic library with version In-Reply-To: <1a3bda84-363d-b82e-191c-ce3761bbed59@yandex.ru> References: <1a3bda84-363d-b82e-191c-ce3761bbed59@yandex.ru> Message-ID: <20171211100615.6deb890b@ckandeler-archlinux> On Sat, 9 Dec 2017 17:00:34 +0300 Карелин Павел wrote: > I need to connect the dynamic library 'soxr' to the QBS project. > The system has a symlink of libsoxr.so.0 (with the version), but not > libsoxr.so > How can I connect to the project libsoxr.so.0? You can give the full file path in that case. Using ld's ":" syntax should also work; at least I don't think we fiddle with the string. Christian From hkarel at yandex.ru Mon Dec 11 10:51:22 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Mon, 11 Dec 2017 12:51:22 +0300 Subject: [Qbs] Linking dynamic library with version In-Reply-To: <20171211100615.6deb890b@ckandeler-archlinux> References: <1a3bda84-363d-b82e-191c-ce3761bbed59@yandex.ru> <20171211100615.6deb890b@ckandeler-archlinux> Message-ID: <6adbd8a9-fb21-57cb-5a4a-e73523e66210@yandex.ru> The recipe ":" has helped. Thank! 11.12.2017 12:06, Christian Kandeler пишет: > On Sat, 9 Dec 2017 17:00:34 +0300 > Карелин Павел wrote: > >> I need to connect the dynamic library 'soxr' to the QBS project. >> The system has a symlink of libsoxr.so.0 (with the version), but not >> libsoxr.so >> How can I connect to the project libsoxr.so.0? > You can give the full file path in that case. Using ld's ":" syntax should also work; at least I don't think we fiddle with the string. > > > Christian > _______________________________________________ > 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 ola at silentwings.no Mon Dec 11 12:38:03 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Mon, 11 Dec 2017 12:38:03 +0100 Subject: [Qbs] Need help with setting up a code generator Message-ID: Hi all, I've got a code generator tool that I'm trying to include in a qbs project. Currently it's been used in a project using qmake, but I'd like to move on to qbs. The code generator (a commandline tool) takes a set of C header files (.h) in a given directory, and another set of template files (names matching .tpl, .h and .cpp) in another directory. The output is a set of C++ .h and .cpp files in an output directory. The number of output files is not the same as the number of input files. The resulting .h and .cpp files are to be built into a static library. Also those header files must be available in the includepath to those needing it. Whenever any of the C headers or template files are modified, the code generator is to be run again. I'd really appreciate some hints or examples on how this can be done, I'm currently stuck trying to figure it out. Best regards, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Mon Dec 11 13:27:28 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 11 Dec 2017 13:27:28 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: References: Message-ID: <20171211132728.348a70d9@ckandeler-archlinux> On Mon, 11 Dec 2017 12:38:03 +0100 Ola Røer Thorsen wrote: > The code generator (a commandline tool) takes a set of C header files (.h) > in a given directory, and another set of template files (names matching > .tpl, .h and .cpp) in another directory. StaticLibrary { Depends { name: "cpp" } Group { name: "header inputs" files: ["dir1/*.h"] fileTags: ["generator.in.headers"] } Group { name: "template inputs" prefix: "dir2/" files: ["*.tpl", "*.h", "*.cpp] fileTags: ["generator.in.templates"] } > The output is a set of C++ .h and > .cpp files in an output directory. The number of output files is not the > same as the number of input files. Rule { // See https://doc.qt.io/qbs/rule-item.html for details. multiplex: true // Probably. Not entirely clear from your description inputs: ["generator.in.headers", "generator.in.templates"] // I assume the number of output files is dynamic and depends on // the number and/or contents of the input files. outputFileTags: ["h", "cpp"] outputArtifacts: { // The following two are arrays of artifact objects. // Their file paths are available via the filePath property. var headerInputs = inputs["generator.in.headers"]; var templateInputs = inputs["generator.in.templates"]; var outList = []; // Do what you need to do here to calculate the output // from the input artifacts. The return value is a list of // objects with properties filePath and fileTags. return outList; } prepare: { var generatorArgs = []; // Generate the command-line arguments for the generator tool // from the inputs and outputs variables. var cmd = new Command("generator.exe", generatorArgs); cmd.description = "Running generator"; return [cmd]; } // Use this property in the outputArtifacts script above. property string generatedIncludesDir: product.buildDirectory + "/includes" > The resulting .h and .cpp files are to be built into a static library. Also > those header files must be available in the includepath to those needing > it. Export { Depends { name: "cpp" } cpp.includePaths: product.generatedIncludesDir } } > Whenever any of the C headers or template files are modified, the code > generator is to be run again. This is basic built-in functionality. > I'd really appreciate some hints or examples on how this can be done, I'm > currently stuck trying to figure it out. Hope this helps, Christian From hkarel at yandex.ru Mon Dec 11 17:58:27 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Mon, 11 Dec 2017 19:58:27 +0300 Subject: [Qbs] qm-file build as internal resource Message-ID: Hi, I'm build a third-party project. The peculiarity of the project is that qm-files are represented as internal resources. Now I solved the problem with a terrible hack: 1) Created the 'Translations' product Product {     name: "Translations"     type: "qm"     destinationDirectory: project.sourceDirectory + "/translations"     Depends { name: "Qt.core" }     files: ["*.ts"] } 2) The results of the work 'Translations' are located in the project.sourceDirectory + "/translations" directory 3) The main product made dependent on 'Translations' Depends { name: "Translations" } 4) In the main product I cling the created qm-files through a qrc-resource     Group {         name: "translations"         files: ["translations/translations.qrc"]     } Is it possible to solve this task in another way? qm-resources should be placed by the path ":translations/" -- BR, Pavel Karelin -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Mon Dec 11 22:03:58 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 12 Dec 2017 10:03:58 +1300 Subject: [Qbs] Qtc+Qbs+git wroktree = cannot lock build graph Message-ID: Hi there, Not sure if it's a Qtc or a Qbs issue, but here is my problem: I'm using git worktrees, which means i have the same project checked-out on different branches in different sibling directories, the main qbs files have the same name, and so by default, Qtc try to use the same build directory, luckily qbs refuse to go ahead (not sure if with qmake i'll get a warning about that). Anyway, the solution is to edit the project's build settings. It's OK, but it's a bit annoying over time. What about if Qtc would hash the path to the project file and use it (as a prefix) to name the default build folder? Chris From christian.kandeler at qt.io Tue Dec 12 09:49:26 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 12 Dec 2017 09:49:26 +0100 Subject: [Qbs] qm-file build as internal resource In-Reply-To: References: Message-ID: <20171212094926.4bec1549@ckandeler-archlinux> On Mon, 11 Dec 2017 19:58:27 +0300 Карелин Павел wrote: > I'm build a third-party project. The peculiarity of the project is that > qm-files are represented as internal resources. > Now I solved the problem with a terrible hack: > 1) Created the 'Translations' product > Product { >     name: "Translations" >     type: "qm" >     destinationDirectory: project.sourceDirectory + "/translations" > >     Depends { name: "Qt.core" } >     files: ["*.ts"] > } > > 2) The results of the work 'Translations' are located in the > project.sourceDirectory + "/translations" directory > 3) The main product made dependent on 'Translations' > Depends { name: "Translations" } > > 4) In the main product I cling the created qm-files through a qrc-resource >     Group { >         name: "translations" >         files: ["translations/translations.qrc"] >     } > > Is it possible to solve this task in another way? > qm-resources should be placed by the path ":translations/" You left out some details, so I have to take a guess. I assume you are listing the qm files "manually" in the qrc file, and that's what you want to get rid of? In that case, something like the following looks adequate: QtApplication { // Or whatever the main product is Group { name: "translations" files: ["/*.ts"] } Group { fileTagsFilter: ["qm"] fileTags: ["qt.core.resource_data"] } // See doc.qt.io/qbs/qt-modules.html#core-properties // for details. Qt.core.resourceSourceBase: Qt.core.qmDir Qt.core.resourcePrefix: "translations" } This should auto-generate the qrc file. Christian From ola at silentwings.no Tue Dec 12 10:30:18 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Tue, 12 Dec 2017 10:30:18 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: <20171211132728.348a70d9@ckandeler-archlinux> References: <20171211132728.348a70d9@ckandeler-archlinux> Message-ID: Thanks a lot for the help, Christian! 2017-12-11 13:27 GMT+01:00 Christian Kandeler : > Group { > name: "header inputs" > files: ["dir1/*.h"] > fileTags: ["generator.in.headers"] > } > Group { > name: "template inputs" > prefix: "dir2/" > files: ["*.tpl", "*.h", "*.cpp] > fileTags: ["generator.in.templates"] > } > > Is there some way to debug-print the contents of these groups as I go along writing the qbs file? > Rule { > // See https://doc.qt.io/qbs/rule-item.html for details. > multiplex: true // Probably. Not entirely clear from your > description > Yes multiplex seems to be the correct option here. > inputs: ["generator.in.headers", "generator.in.templates"] > > // I assume the number of output files is dynamic and depends on > // the number and/or contents of the input files. > outputFileTags: ["h", "cpp"] > outputArtifacts: { > // The following two are arrays of artifact objects. > // Their file paths are available via the filePath property. > var headerInputs = inputs["generator.in.headers"]; > var templateInputs = inputs["generator.in.templates"]; > > var outList = []; > // Do what you need to do here to calculate the output > // from the input artifacts. The return value is a list of > // objects with properties filePath and fileTags. > return outList; > } > Does this mean I need to know the exact list of files the code generator outputs before it is run? Normally I'd only know that after having run the code generator and look into it's output directory. Currently I'm trying to print the contents of headerInputs and templateInputs like this, var headerInputs = inputs["generator.in.headers"]; var templateInputs = inputs["generator.in.templates"]; console.warn("headerInputs: " + headerInputs); console.warn("templateInputs: " + templateInputs); But the output says "headerInputs: undefined" and "templateInputs: undefined" > prepare: { > var generatorArgs = []; > // Generate the command-line arguments for the generator tool > // from the inputs and outputs variables. > var cmd = new Command("generator", generatorArgs); > cmd.description = "Running generator"; > return [cmd]; > } > > I've hit some issue with the argument list/array. One of my argument strings contain a wildcard '*', which casues that string to be wrapped with '. var generatorArgs = [ product.sourceDirectory + "/api/some*files.h"), "-o", product.buildDirectory + "/gen/", ]; The actual command line has the first string wrapped in ' ' because of the * in the string (wildcards are used for the input to the generator tool). The code generator doesn't cope with the wrapping in '' (neither will "ls" or any other command). Here is the resulting command line: /home/xxxxx/bin/generator '/home/xxx/api/some*files.h' -o /home/xxx/build-xxx-Desktop_Qt_5_10_0_GCC_64bit-Debug/qtc_Desktop_Qt_5_10_0_GCC_64bit_Debug/xxx.3a7a69e5/gen/ Why does the Command object add the '' around strings with * in them, and is there some way to avoid that? Best regards, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Tue Dec 12 11:00:00 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 12 Dec 2017 11:00:00 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: References: <20171211132728.348a70d9@ckandeler-archlinux> Message-ID: <20171212110000.26e9fe77@ckandeler-archlinux> On Tue, 12 Dec 2017 10:30:18 +0100 Ola Røer Thorsen wrote: > Is there some way to debug-print the contents of these groups as I go along > writing the qbs file? You could use the status command. Or, if you are using Qt Creator, they are simply listed in the project tree. > Does this mean I need to know the exact list of files the code generator > outputs before it is run? Normally I'd only know that after having run the > code generator and look into it's output directory. Then you'll have to run the tool in the outputArtifacts script already. Unless the tool has some special "dry-run" option, the actual command could then become a dummy. The cleaner solution, assuming the tool is under your control, would be to give it such an option that prints a suitably formatted list of the outputs it would produce. > Currently I'm trying to print the contents of headerInputs and > templateInputs like this, > > var headerInputs = inputs["generator.in.headers"]; > var templateInputs = inputs["generator.in.templates"]; > > console.warn("headerInputs: " + headerInputs); > console.warn("templateInputs: " + templateInputs); You'd typically use JSON.stringify here. > But the output says "headerInputs: undefined" and "templateInputs: > undefined" That means you don't have any inputs with these tags. Double-check the spelling. There must be some sort of match though, because otherwise the rule would not have run (assuming you did not force it by setting alwaysRun or requiresInputs). You can see all the inputs, including their file tags, by printing JSON.stringify(inputs). > > prepare: { > > var generatorArgs = []; > > // Generate the command-line arguments for the generator tool > > // from the inputs and outputs variables. > > var cmd = new Command("generator", generatorArgs); > > cmd.description = "Running generator"; > > return [cmd]; > > } > > > > > I've hit some issue with the argument list/array. One of my argument > strings contain a wildcard '*', which casues that string to be wrapped with > '. > > var generatorArgs = [ > product.sourceDirectory + "/api/some*files.h"), This looks like the wrong thing to do. If you pass some wildcard strings instead of actual files, you are circumventing the build system, as it cannot do change tracking on the expanded files. Instead, you should only pass actual file paths derived from the rule inputs. > Why does the Command object add the '' around strings with * in them, and > is there some way to avoid that? To prevent shell expansion, as the arguments are supposed to go to the command as-is. There has not yet been a use case to opt out of this, and I don't think yours is a valid one (as explained above). Christian From hkarel at yandex.ru Tue Dec 12 12:26:31 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Tue, 12 Dec 2017 14:26:31 +0300 Subject: [Qbs] qm-file build as internal resource In-Reply-To: <20171212094926.4bec1549@ckandeler-archlinux> References: <20171212094926.4bec1549@ckandeler-archlinux> Message-ID: 12.12.2017 11:49, Christian Kandeler пишет: > On Mon, 11 Dec 2017 19:58:27 +0300 > Карелин Павел wrote: > >> I'm build a third-party project. The peculiarity of the project is that >> qm-files are represented as internal resources. >> Now I solved the problem with a terrible hack: >> 1) Created the 'Translations' product >> Product { >>     name: "Translations" >>     type: "qm" >>     destinationDirectory: project.sourceDirectory + "/translations" >> >>     Depends { name: "Qt.core" } >>     files: ["*.ts"] >> } >> >> 2) The results of the work 'Translations' are located in the >> project.sourceDirectory + "/translations" directory >> 3) The main product made dependent on 'Translations' >> Depends { name: "Translations" } >> >> 4) In the main product I cling the created qm-files through a qrc-resource >>     Group { >>         name: "translations" >>         files: ["translations/translations.qrc"] >>     } >> >> Is it possible to solve this task in another way? >> qm-resources should be placed by the path ":translations/" > You left out some details, so I have to take a guess. I assume you are listing the qm files "manually" in the qrc file, and that's what you want to get rid of? > In that case, something like the following looks adequate: > > QtApplication { // Or whatever the main product is > Group { > name: "translations" > files: ["/*.ts"] > } > Group { > fileTagsFilter: ["qm"] > fileTags: ["qt.core.resource_data"] > } > > // See doc.qt.io/qbs/qt-modules.html#core-properties > // for details. > Qt.core.resourceSourceBase: Qt.core.qmDir > Qt.core.resourcePrefix: "translations" > } > > This should auto-generate the qrc file. Christian, you were right in your guess. Indeed, the file translations.qrc is filled manually. Sorry that did not write about this at once. But unfortunately your recipe did not work. I see that qm-files are created in the assembly directory, but there is no resulting qrc-file. In addition, I have a couple more groups with resources. Will these groups be handled correctly?     Group {         name: "smileys"         files: {             var f = [];             if (project.useSmileys === "yes")                 f = ["smileys/emojione.qrc"];             else if (project.useSmileys === "min")                 f = ["smileys/smileys.qrc"];             return f;         }     }     Group {         name: "resources"         files: [             "res.qrc",         ]     } P.S. I can provide a link to the project on github, if that helps. > > > Christian > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs From ola at silentwings.no Tue Dec 12 14:20:01 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Tue, 12 Dec 2017 14:20:01 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: <20171212110000.26e9fe77@ckandeler-archlinux> References: <20171211132728.348a70d9@ckandeler-archlinux> <20171212110000.26e9fe77@ckandeler-archlinux> Message-ID: > > > > Does this mean I need to know the exact list of files the code generator > > outputs before it is run? Normally I'd only know that after having run > the > > code generator and look into it's output directory. > > Then you'll have to run the tool in the outputArtifacts script already. > Unless the tool has some special "dry-run" option, the actual command could > then become a dummy. > The cleaner solution, assuming the tool is under your control, would be to > give it such an option that prints a suitably formatted list of the outputs > it would produce. > > I'm not able to change the tool unfortunately. So I'll have to cope even if it's less than optimal. - If any of the input files (headers and templates) are modified, the generator tool must be run, and all the .cpp files it produces must be rebuilt. - The number of output files depend on the contents of any of the input files and is beyond my control - I can have the generator output text files containing the names of the generated files. To run the command inside the outputArtifacts script, I'll use the Process object, right? What is the exact condition for when this script is run? Is it only whenever any of the inputs are modified (or the qbs file I guess)? What's the simplest way to define a dummy command in the prepare-script? > var generatorArgs = [ > > product.sourceDirectory + "/api/some*files.h"), > > This looks like the wrong thing to do. If you pass some wildcard strings > instead of actual files, you are circumventing the build system, as it > cannot do change tracking on the expanded files. > Instead, you should only pass actual file paths derived from the rule > inputs. > > > Why does the Command object add the '' around strings with * in them, and > > is there some way to avoid that? > > To prevent shell expansion, as the arguments are supposed to go to the > command as-is. There has not yet been a use case to opt out of this, and I > don't think yours is a valid one (as explained above). > > Ok fair enough. It's how the generator tool is usually called here, but I can create a list from the inputs array instead. Thanks again for all the help! Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Tue Dec 12 14:24:30 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 12 Dec 2017 14:24:30 +0100 Subject: [Qbs] qm-file build as internal resource In-Reply-To: References: <20171212094926.4bec1549@ckandeler-archlinux> Message-ID: <20171212142430.540a0172@ckandeler-archlinux> On Tue, 12 Dec 2017 14:26:31 +0300 Карелин Павел wrote: > But unfortunately your recipe did not work. I see that qm-files > are created in the assembly directory, but there is no resulting > qrc-file. Are you sure you are using qbs >= 1.10? > In addition, I have a couple more groups with resources. Will > these groups be handled correctly? Yes, the qrc files are independent of each other. > P.S. I can provide a link to the project on github, if that helps. If you are using the latest qbs release and it still does not work, then yes, please do. Christian From christian.kandeler at qt.io Tue Dec 12 14:29:36 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 12 Dec 2017 14:29:36 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: References: <20171211132728.348a70d9@ckandeler-archlinux> <20171212110000.26e9fe77@ckandeler-archlinux> Message-ID: <20171212142936.5f845d9d@ckandeler-archlinux> On Tue, 12 Dec 2017 14:20:01 +0100 Ola Røer Thorsen wrote: > To run the command inside the outputArtifacts script, I'll use the Process > object, right? Yes. > What is the exact condition for when this script is run? Is it only > whenever any of the inputs are modified (or the qbs file I guess)? Whenever any input has a timestamp newer than any output, or if a property accessed in the rule has changed its value since the last run, or if the rule source code has changed. Modifications to the qbs file only cause rule re-execution if there are relevant changes as described above. > What's the simplest way to define a dummy command in the prepare-script? var cmd = new JavaScriptCommand(); cmd.silent = true; // Or cmd.description = ""; cmd.sourceCode = function() {} Christian From Jake.Petroules at qt.io Tue Dec 12 23:38:32 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 12 Dec 2017 22:38:32 +0000 Subject: [Qbs] PSA: Qbs repository URL has changed Message-ID: Hi all, This message is to inform any users who may have a Qbs checkout, that the URL has changed. The old repository URL was qt-labs/qbs, and it has now changed to qbs/qbs: https://code.qt.io/cgit/qbs/qbs.git/ Please update your git remotes as necessary. -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From chgans at gmail.com Wed Dec 13 06:10:42 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 13 Dec 2017 18:10:42 +1300 Subject: [Qbs] Qbs system settings Message-ID: <6f5b2d7d-8944-82fe-6d4e-10ed9fd7facb@gmail.com> Hi there, I would like to setup qbs profile system wide, I have tried using the '--settings-dir' (eg qbs-setup-qt --settings-dir /etc/xdg), but then qbs-config doesn't seem to read the system settings. $ /opt/qt/5.6/bin/qtpaths --paths GenericConfigLocation /root/.config:/etc/xdg $ /opt/qt/5.6/bin/qtpaths --paths ConfigLocation /root/.config:/etc/xdg I would expect that qbs-config would see profiles defined system-wise too. But it seems that i need to use qbs-config --settings-dir Can Qbs pick up build profiles defined system-wide? I have try as well with --settings-dir /etc/xdg/QtProject, but it doesn't make any difference Thanks, Chris From ola at silentwings.no Wed Dec 13 11:59:40 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Wed, 13 Dec 2017 11:59:40 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: <20171212142936.5f845d9d@ckandeler-archlinux> References: <20171211132728.348a70d9@ckandeler-archlinux> <20171212110000.26e9fe77@ckandeler-archlinux> <20171212142936.5f845d9d@ckandeler-archlinux> Message-ID: Hi Christian, thanks a lot for all your input. The build is very efficient now. The final solution was a partial "dry run" of the generator tool to help create the list of artifacts, and the usual full run in the "prepare" script. Now that this is working we'll start migrating from qmake to qbs completely. The QtCreator integration seems to be much more stable now with the latest release as well. Best regards, Ola 2017-12-12 14:29 GMT+01:00 Christian Kandeler : > On Tue, 12 Dec 2017 14:20:01 +0100 > Ola Røer Thorsen wrote: > > > To run the command inside the outputArtifacts script, I'll use the > Process > > object, right? > > Yes. > > > What is the exact condition for when this script is run? Is it only > > whenever any of the inputs are modified (or the qbs file I guess)? > > Whenever any input has a timestamp newer than any output, or if a property > accessed in the rule has changed its value since the last run, or if the > rule source code has changed. > Modifications to the qbs file only cause rule re-execution if there are > relevant changes as described above. > > > What's the simplest way to define a dummy command in the prepare-script? > > var cmd = new JavaScriptCommand(); > cmd.silent = true; // Or cmd.description = ""; > cmd.sourceCode = function() {} > > > Christian > _______________________________________________ > 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 ola at silentwings.no Wed Dec 13 16:16:41 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Wed, 13 Dec 2017 16:16:41 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: References: <20171211132728.348a70d9@ckandeler-archlinux> <20171212110000.26e9fe77@ckandeler-archlinux> <20171212142936.5f845d9d@ckandeler-archlinux> Message-ID: Now I've got a new problem related to the code generated library. I've set up a second version of the library (new templates, basically), where the code generated is using Qt. So there are a few QObject-based classes etc. My Rule item that produces the files are setting the fileTags "h" for the headers and "cpp" for the cpp files being created. Moc is never run on any of the header files, so there are no additional moc_xxx.cpp files being created and built. This results in lots of unresolved references in the end once someone tries to use the library. How do I make sure moc is run on the autogenerated header files so that the additional moc code is generated as well? Thanks, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Wed Dec 13 17:36:16 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 13 Dec 2017 17:36:16 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: References: <20171211132728.348a70d9@ckandeler-archlinux> <20171212110000.26e9fe77@ckandeler-archlinux> <20171212142936.5f845d9d@ckandeler-archlinux> Message-ID: <20171213173616.40614364@ckandeler-archlinux> On Wed, 13 Dec 2017 16:16:41 +0100 Ola Røer Thorsen wrote: > Now I've got a new problem related to the code generated library. I've set > up a second version of the library (new templates, basically), where the > code generated is using Qt. So there are a few QObject-based classes etc. > > My Rule item that produces the files are setting the fileTags "h" for the > headers and "cpp" for the cpp files being created. Moc is never run on any > of the header files, so there are no additional moc_xxx.cpp files being > created and built. This results in lots of unresolved references in the end > once someone tries to use the library. > > How do I make sure moc is run on the autogenerated header files so that the > additional moc code is generated as well? That happens automatically if the product has a dependency on the Qt.core module. Note: The correct file tag for headers is "hpp" (not "h", as I wrote in my first reply.) Christian From ola at silentwings.no Thu Dec 14 15:37:45 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Thu, 14 Dec 2017 15:37:45 +0100 Subject: [Qbs] Need help with setting up a code generator In-Reply-To: <20171213173616.40614364@ckandeler-archlinux> References: <20171211132728.348a70d9@ckandeler-archlinux> <20171212110000.26e9fe77@ckandeler-archlinux> <20171212142936.5f845d9d@ckandeler-archlinux> <20171213173616.40614364@ckandeler-archlinux> Message-ID: 2017-12-13 17:36 GMT+01:00 Christian Kandeler : > > That happens automatically if the product has a dependency on the Qt.core > module. > Note: The correct file tag for headers is "hpp" (not "h", as I wrote in my > first reply.) > > Yes using "hpp" fixed it, thanks :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ola at silentwings.no Thu Dec 14 15:52:03 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Thu, 14 Dec 2017 15:52:03 +0100 Subject: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit? Message-ID: I'm trying to build a project that has some assembly files as well as C++ code. I'm building from QtCreator using the latest Qt 5.10 release kit (Linux x86_64) on KDE Neon. The assembly files are added to the files property along with the rest, and end with .asm. While building qbs seems to just ignore these, and I suspect it's because the toolchain has no assembler defined. How can I tell it to use nasm while still using the default kit found in QtCreator? I've tried setting the cpp.assemblerName and cpp.assemblerPath properties in my project file but it doesn't seem to have any effect. Cheers, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.courtois at gmail.com Thu Dec 14 16:21:42 2017 From: damien.courtois at gmail.com (Damien Courtois) Date: Thu, 14 Dec 2017 16:21:42 +0100 Subject: [Qbs] qbs run --dry-run not working ? Message-ID: Hi, I'm not sure if this is a bug or me not understanding the documentation, but when I use `qbs run [...] --dry-run profile:foo debug` my project is still started. Isn't this option supposed to suppress the actual command executions ? As a side note, I'm doing this to get the full path to the executable of my project. It's the only way I found, but I'd like to avoid starting the executable just to get this information. Maybe there is a better way to query this kind of information ? Regards, Damien Courtois -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Thu Dec 14 17:27:27 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 14 Dec 2017 17:27:27 +0100 Subject: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit? In-Reply-To: References: Message-ID: <20171214172727.496553f5@ckandeler-archlinux> On Thu, 14 Dec 2017 15:52:03 +0100 Ola Røer Thorsen wrote: > I'm trying to build a project that has some assembly files as well as C++ > code. I'm building from QtCreator using the latest Qt 5.10 release kit > (Linux x86_64) on KDE Neon. > > The assembly files are added to the files property along with the rest, and > end with .asm. While building qbs seems to just ignore these, and I suspect > it's because the toolchain has no assembler defined. Have you tagged them properly? The .asm extension is not auto-tagged on Linux; you will need to do that "manually" via a Group or a FileTagger item. See https://doc.qt.io/qbs/cpp-module.html#relevant-file-tags for the assembler-related file tags. Christian From christian.kandeler at qt.io Thu Dec 14 17:38:07 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 14 Dec 2017 17:38:07 +0100 Subject: [Qbs] qbs run --dry-run not working ? In-Reply-To: References: Message-ID: <20171214173807.6c36e324@ckandeler-archlinux> On Thu, 14 Dec 2017 16:21:42 +0100 Damien Courtois wrote: > I'm not sure if this is a bug or me not understanding the documentation, > but when I use `qbs run [...] --dry-run profile:foo debug` my project is > still started. > Isn't this option supposed to suppress the actual command executions ? The --dry-run option is a build option and thus "command execution" refers to compilers and such. It's only available for "run" because "run" includes "build" as a sub-step. If I understand you correctly, you want output such as "would try to run "? I suppose that could be added. > As a side note, I'm doing this to get the full path to the executable of my > project. It's the only way I found, but I'd like to avoid starting the > executable just to get this information. Maybe there is a better way to > query this kind of information ? We don't currently have command-line options for this, though this sounds as if it would fit as an extension to the list-products command. What are you planning to do with that information? Christian From ola at silentwings.no Thu Dec 14 17:46:56 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Thu, 14 Dec 2017 17:46:56 +0100 Subject: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit? In-Reply-To: <20171214172727.496553f5@ckandeler-archlinux> References: <20171214172727.496553f5@ckandeler-archlinux> Message-ID: 2017-12-14 17:27 GMT+01:00 Christian Kandeler : > Have you tagged them properly? The .asm extension is not auto-tagged on > Linux; you will need to do that "manually" via a Group or a FileTagger > item. > See https://doc.qt.io/qbs/cpp-module.html#relevant-file-tags for the > assembler-related file tags. > > Ah, I missed that bit with ".asm" being automatically tagget only for MSVC. It's running when I tag the files with "asm", but using the assembler "as" instead of "nasm". Any way to override that here for this particular group of files? The source files are not compatible with "as". Thanks, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Thu Dec 14 18:02:47 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 14 Dec 2017 18:02:47 +0100 Subject: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit? In-Reply-To: References: <20171214172727.496553f5@ckandeler-archlinux> Message-ID: <20171214180247.410bd008@ckandeler-archlinux> On Thu, 14 Dec 2017 17:46:56 +0100 Ola Røer Thorsen wrote: > It's running when I tag the files with "asm", but using the assembler "as" > instead of "nasm". Any way to override that here for this particular group > of files? The source files are not compatible with "as". You need to set cpp.assemblerName, either in the profile or in your product(s). Christian From damien.courtois at gmail.com Thu Dec 14 18:19:22 2017 From: damien.courtois at gmail.com (Damien Courtois) Date: Thu, 14 Dec 2017 18:19:22 +0100 Subject: [Qbs] qbs run --dry-run not working ? In-Reply-To: <20171214173807.6c36e324@ckandeler-archlinux> References: <20171214173807.6c36e324@ckandeler-archlinux> Message-ID: Thanks for the answer ! I'm currently working on integrating Qbs into another IDE. In this IDE, I let the user point to the Qbs executable, optionally select a settings folder and various other options. Then through the IDE, I let the user select his profile and configuration, and finally I let him build, clean and run the project. To do that, I need to be able to easily get a list of available profiles from Qbs (this one is pretty easy, I just need to parse the output of `qbs config --list`), a list of available configurations (for the moment I'm just exposing "debug" and "release", I have no idea how to get that information) and the full path to the built executable (assuming the project is a simple executable) I can't just run it using Qbs because the IDE's debugger would attach to Qbs instead of the actual executable to debug. Currently I'm using `qbs config --list` to get the list of profiles, and the only way to get the full path to the built executable is using `qbs run`: it outputs something like Starting target 'D:\Development\IsoDarts\build\Qbs\debug\IsoDarts.e08a60cd\IsoDarts.exe'. which I can parse, and then feed to the IDE's debugger. But you can easily see that it's prone to errors, changes in the way Qbs logs things to the stdout, etc. So it would be awesome if Qbs was providing a sort of unified `query` command (or something similar) that would let us extract informations about Qbs and the project in a clear documented way (Ideally outputing in JSON format or a similarly easy to parse format) This way Qbs would be very easy to integrate into existing toolsets. Damien 2017-12-14 17:38 GMT+01:00 Christian Kandeler : > On Thu, 14 Dec 2017 16:21:42 +0100 > Damien Courtois wrote: > > > I'm not sure if this is a bug or me not understanding the documentation, > > but when I use `qbs run [...] --dry-run profile:foo debug` my project is > > still started. > > Isn't this option supposed to suppress the actual command executions ? > > The --dry-run option is a build option and thus "command execution" refers > to compilers and such. It's only available for "run" because "run" includes > "build" as a sub-step. > If I understand you correctly, you want output such as "would try to run > "? I suppose that could be added. > > > As a side note, I'm doing this to get the full path to the executable of > my > > project. It's the only way I found, but I'd like to avoid starting the > > executable just to get this information. Maybe there is a better way to > > query this kind of information ? > > We don't currently have command-line options for this, though this sounds > as if it would fit as an extension to the list-products command. > What are you planning to do with that information? > > > Christian > _______________________________________________ > 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 Jake.Petroules at qt.io Thu Dec 14 19:33:01 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 14 Dec 2017 18:33:01 +0000 Subject: [Qbs] qbs run --dry-run not working ? In-Reply-To: References: <20171214173807.6c36e324@ckandeler-archlinux> Message-ID: Hi Damien, Out of curiosity, which IDE are you integrating Qbs into? We've actually done some prior work on Qbs IDE integration; you might want to look into the src/plugins/generator directory of the Qbs sources where you can find a Visual Studio integration. There's also the Qbs Qt Creator plugin which you can investigate. > On Dec 14, 2017, at 9:19 AM, Damien Courtois wrote: > > Thanks for the answer ! > > I'm currently working on integrating Qbs into another IDE. In this IDE, I let the user point to the Qbs executable, optionally select a settings folder and various other options. > Then through the IDE, I let the user select his profile and configuration, and finally I let him build, clean and run the project. > > To do that, I need to be able to easily get a list of available profiles from Qbs (this one is pretty easy, I just need to parse the output of `qbs config --list`), a list of available configurations (for the moment I'm just exposing "debug" and "release", I have no idea how to get that information) and the full path to the built executable (assuming the project is a simple executable) I can't just run it using Qbs because the IDE's debugger would attach to Qbs instead of the actual executable to debug. > > Currently I'm using `qbs config --list` to get the list of profiles, and the only way to get the full path to the built executable is using `qbs run`: it outputs something like > Starting target 'D:\Development\IsoDarts\build\Qbs\debug\IsoDarts.e08a60cd\IsoDarts.exe'. which I can parse, and then feed to the IDE's debugger. > > But you can easily see that it's prone to errors, changes in the way Qbs logs things to the stdout, etc. > > So it would be awesome if Qbs was providing a sort of unified `query` command (or something similar) that would let us extract informations about Qbs and the project in a clear documented way (Ideally outputing in JSON format or a similarly easy to parse format) > This way Qbs would be very easy to integrate into existing toolsets. > > Damien > > > > 2017-12-14 17:38 GMT+01:00 Christian Kandeler : > On Thu, 14 Dec 2017 16:21:42 +0100 > Damien Courtois wrote: > > > I'm not sure if this is a bug or me not understanding the documentation, > > but when I use `qbs run [...] --dry-run profile:foo debug` my project is > > still started. > > Isn't this option supposed to suppress the actual command executions ? > > The --dry-run option is a build option and thus "command execution" refers to compilers and such. It's only available for "run" because "run" includes "build" as a sub-step. > If I understand you correctly, you want output such as "would try to run "? I suppose that could be added. > > > As a side note, I'm doing this to get the full path to the executable of my > > project. It's the only way I found, but I'd like to avoid starting the > > executable just to get this information. Maybe there is a better way to > > query this kind of information ? > > We don't currently have command-line options for this, though this sounds as if it would fit as an extension to the list-products command. > What are you planning to do with that information? > > > Christian > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs > > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From ola at silentwings.no Thu Dec 14 21:01:03 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Thu, 14 Dec 2017 21:01:03 +0100 Subject: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit? In-Reply-To: <20171214180247.410bd008@ckandeler-archlinux> References: <20171214172727.496553f5@ckandeler-archlinux> <20171214180247.410bd008@ckandeler-archlinux> Message-ID: 2017-12-14 18:02 GMT+01:00 Christian Kandeler : > On Thu, 14 Dec 2017 17:46:56 +0100 > Ola Røer Thorsen wrote: > > > It's running when I tag the files with "asm", but using the assembler > "as" > > instead of "nasm". Any way to override that here for this particular > group > > of files? The source files are not compatible with "as". > > You need to set cpp.assemblerName, either in the profile or in your > product(s). > > Right. I had only tried setting it inside the Group item, but that didn't have any effect. I need another Properties item instead to conditionally set the cpp.assemblerName then? Group { name: "asm-linux-x86_64" condition: qbs.architecture === "x86_64" files: [ ...the .asm files ] cpp.assemblerName: "nasm" } I'll have a similar Group item containing assembly code for linux armv5t and yet another one for Windows, that's why I tried setting the cpp.assemblerName inside the group. Setting cpp.assemblerName outside the Group item makes qbs run nasm, but then it's using some options tailored for "as" (I guess) that won't work with nasm: nasm: error: unrecognised option `--64' type `nasm -h' for help At this point I'm probably better of writing my own Rule item to process each of the .asm files using nasm, to have full control? (output artifacts tagged with "obj"?) Cheers, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Dec 15 06:11:09 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 15 Dec 2017 08:11:09 +0300 Subject: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit? In-Reply-To: References: <20171214172727.496553f5@ckandeler-archlinux> <20171214180247.410bd008@ckandeler-archlinux> Message-ID: <07e47300-e8b4-9d1c-21c3-11433d08e06a@gmail.com> > I'll have a similar Group item containing assembly Hi, seems, you need to use Properties item instead of Group item to use cpp.assemblerName . BR, Denis 14.12.2017 23:01, Ola Røer Thorsen пишет: > 2017-12-14 18:02 GMT+01:00 Christian Kandeler > >: > > On Thu, 14 Dec 2017 17:46:56 +0100 > Ola Røer Thorsen > > wrote: > > > It's running when I tag the files with "asm", but using the > assembler "as" > > instead of "nasm". Any way to override that here for this > particular group > > of files? The source files are not compatible with "as". > > You need to set cpp.assemblerName, either in the profile or in > your product(s). > > > Right. I had only tried setting it inside the Group item, but that > didn't have any effect. I need another Properties item instead to > conditionally set the cpp.assemblerName then? > > Group { >     name: "asm-linux-x86_64" >     condition: qbs.architecture === "x86_64" >     files: [ ...the .asm files ] >     cpp.assemblerName: "nasm" > } > > I'll have a similar Group item containing assembly code for linux > armv5t and yet another one for Windows, that's why I tried setting the > cpp.assemblerName inside the group. > > Setting cpp.assemblerName outside the Group item makes qbs run nasm, > but then it's using some options tailored for "as" (I guess) that > won't work with nasm: > nasm: error: unrecognised option `--64' > type `nasm -h' for help > > At this point I'm probably better of writing my own Rule item to > process each of the .asm files using nasm, to have full control? > (output artifacts tagged with "obj"?) > > Cheers, > Ola > > > > _______________________________________________ > 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 christian.kandeler at qt.io Fri Dec 15 10:07:33 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 15 Dec 2017 10:07:33 +0100 Subject: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit? In-Reply-To: References: <20171214172727.496553f5@ckandeler-archlinux> <20171214180247.410bd008@ckandeler-archlinux> Message-ID: <20171215100733.493e203c@ckandeler-archlinux> On Thu, 14 Dec 2017 21:01:03 +0100 Ola Røer Thorsen wrote: > > You need to set cpp.assemblerName, either in the profile or in your > > product(s). > > > Right. I had only tried setting it inside the Group item, but that didn't > have any effect. I need another Properties item instead to conditionally > set the cpp.assemblerName then? > > Group { > name: "asm-linux-x86_64" > condition: qbs.architecture === "x86_64" > files: [ ...the .asm files ] > cpp.assemblerName: "nasm" > } That's due to an implementation detail in the cpp module: The assembler path is read from the product-global instance, not from the per-artifact one. We can easily change that, but are you really using different assembler binaries within the same product? > I'll have a similar Group item containing assembly code for linux armv5t > and yet another one for Windows, that's why I tried setting the > cpp.assemblerName inside the group. Within the same product? What's the final output binary then? > Setting cpp.assemblerName outside the Group item makes qbs run nasm, but > then it's using some options tailored for "as" (I guess) that won't work > with nasm: > nasm: error: unrecognised option `--64' > type `nasm -h' for help Oh, they didn't bother to make their CLI GNU-compatible? That means it's not just a drop-in replacement, but something we need to support explicitly. Can you create a task for that at bugreports.qt.io? Ideally with some more information about this assembler. > At this point I'm probably better of writing my own Rule item to process > each of the .asm files using nasm, to have full control? (output artifacts > tagged with "obj"?) Yes, I suppose so. It's not rocket science. You need to: - tag your assembler files as "nasm" or something like that - write a Rule that - takes "nasm" as input - creates an Artifact with file tag "obj" - creates a Command calling the nasmn binary Maybe you could provide your rule as a reference implementation in the bug report. Alternatively, it might even suffice to do this: cpp.targetAssemblerFlags: [] // Or put nasm-specific stuff in here, if necessary Christian From christian.kandeler at qt.io Fri Dec 15 10:26:46 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 15 Dec 2017 10:26:46 +0100 Subject: [Qbs] Qbs system settings In-Reply-To: <6f5b2d7d-8944-82fe-6d4e-10ed9fd7facb@gmail.com> References: <6f5b2d7d-8944-82fe-6d4e-10ed9fd7facb@gmail.com> Message-ID: <20171215102646.20530887@ckandeler-archlinux> On Wed, 13 Dec 2017 18:10:42 +1300 Christian Gagneraud wrote: > I would like to setup qbs profile system wide, I have tried using the > '--settings-dir' (eg qbs-setup-qt --settings-dir /etc/xdg), but then > qbs-config doesn't seem to read the system settings. > > $ /opt/qt/5.6/bin/qtpaths --paths GenericConfigLocation > /root/.config:/etc/xdg > $ /opt/qt/5.6/bin/qtpaths --paths ConfigLocation > /root/.config:/etc/xdg > > I would expect that qbs-config would see profiles defined system-wise > too. But it seems that i need to use qbs-config --settings-dir > > Can Qbs pick up build profiles defined system-wide? Looking at the source code, the answer seems to be "not reliably". We use QSettings internally, which can look up the system default, but if you give the --settings-dir option, we use a QSettings constructor which doesn't do that. So system-global settings are not really supported at the moment. You might want to file a bug report for that. Christian From christian.kandeler at qt.io Fri Dec 15 10:15:20 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 15 Dec 2017 10:15:20 +0100 Subject: [Qbs] qbs run --dry-run not working ? In-Reply-To: References: <20171214173807.6c36e324@ckandeler-archlinux> Message-ID: <20171215101520.101a3bb4@ckandeler-archlinux> On Thu, 14 Dec 2017 18:19:22 +0100 Damien Courtois wrote: > I'm currently working on integrating Qbs into another IDE. Ah. Well, for this case qbs offers an API; the command line tool is indeed not designed for that. However, the API is Qt-based, so if your IDE is not, then you won't be able to use it. But if it is, then that's the way to go. Christian From damien.courtois at gmail.com Fri Dec 15 11:41:04 2017 From: damien.courtois at gmail.com (Damien Courtois) Date: Fri, 15 Dec 2017 11:41:04 +0100 Subject: [Qbs] Fwd: qbs run --dry-run not working ? In-Reply-To: References: <20171214173807.6c36e324@ckandeler-archlinux> <20171215101520.101a3bb4@ckandeler-archlinux> Message-ID: ---------- 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 at 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 ? 2017-12-15 10:15 GMT+01:00 Christian Kandeler : > On Thu, 14 Dec 2017 18:19:22 +0100 > Damien Courtois wrote: > > > I'm currently working on integrating Qbs into another IDE. > > Ah. Well, for this case qbs offers an API; the command line tool is indeed > not designed for that. However, the API is Qt-based, so if your IDE is not, > then you won't be able to use it. But if it is, then that's the way to go. > > > Christian > _______________________________________________ > 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 christian.kandeler at qt.io Fri Dec 15 12:12:55 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 15 Dec 2017 12:12:55 +0100 Subject: [Qbs] Fwd: qbs run --dry-run not working ? In-Reply-To: References: <20171214173807.6c36e324@ckandeler-archlinux> <20171215101520.101a3bb4@ckandeler-archlinux> Message-ID: <20171215121255.24b872ae@ckandeler-archlinux> 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 at 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 From ola at silentwings.no Fri Dec 15 13:36:16 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Fri, 15 Dec 2017 13:36:16 +0100 Subject: [Qbs] How do I tell qbs to use the nasm assembler when building using QtCreator and a Qt kit? In-Reply-To: <20171215100733.493e203c@ckandeler-archlinux> References: <20171214172727.496553f5@ckandeler-archlinux> <20171214180247.410bd008@ckandeler-archlinux> <20171215100733.493e203c@ckandeler-archlinux> Message-ID: > > > > Group { > > name: "asm-linux-x86_64" > > condition: qbs.architecture === "x86_64" > > files: [ ...the .asm files ] > > cpp.assemblerName: "nasm" > > } > > That's due to an implementation detail in the cpp module: The assembler > path is read from the product-global instance, not from the per-artifact > one. We can easily change that, but are you really using different > assembler binaries within the same product? > > Not at the same time, but I'm building this code for several platforms. It will be deployed on x86_64 linux and windows, and on arm linux, possibly also arm android. The arm version of this code is written in assembly that can be built with the GNU assembler instead of nasm. That's why I wanted to set the assembler name only in the group that had the condition "x86_64"-architecture. Turns out the arm version builds just fine automatically with Qbs as-is as the file extension on those source code files is ".S" and "as" is the assembler to use. This particular static library I'm building here is OpenH264, and it's one of many static libraries and applications being built in a "Project". > > I'll have a similar Group item containing assembly code for linux armv5t > > and yet another one for Windows, that's why I tried setting the > > cpp.assemblerName inside the group. > > Within the same product? What's the final output binary then? > The groups are mutually exclusive, only one of them is used at a time, depending on if I build for windows, x86_64 linux or embedded linux on arm. > > > Setting cpp.assemblerName outside the Group item makes qbs run nasm, but > > then it's using some options tailored for "as" (I guess) that won't work > > with nasm: > > nasm: error: unrecognised option `--64' > > type `nasm -h' for help > > Oh, they didn't bother to make their CLI GNU-compatible? That means it's > not just a drop-in replacement, but something we need to support > explicitly. Can you create a task for that at bugreports.qt.io? Ideally > with some more information about this assembler. > > No I don't think they're aiming for GNU-compatible CLI with nasm. Not even the source code is compatible (different syntax - nasm uses the intel syntax whereas gnu uses AT&T). https://en.wikipedia. org/wiki/Netwide_Assembler I'll create a task with more information. > > At this point I'm probably better of writing my own Rule item to process > > each of the .asm files using nasm, to have full control? (output > artifacts > > tagged with "obj"?) > > Yes, I suppose so. It's not rocket science. You need to: > - tag your assembler files as "nasm" or something like that > - write a Rule that > - takes "nasm" as input > - creates an Artifact with file tag "obj" > - creates a Command calling the nasmn binary > Maybe you could provide your rule as a reference implementation in the bug > report. > > Yeah I tried that yesterday and it works very well (thanks to your help with my previous code generator problem I'm starting to get the hang of it): Rule { inputs: ["nasm"] outputFileTags: ["obj"] Artifact { filePath: input.fileName + ".o" fileTags: ["obj"] } prepare: { var args = ["-I" + product.sourceDirectory + "/codec/common/x86/", "-DUNIX64", "-o", product.buildDirectory + "/" + input.fileName + ".o", input.filePath, ]; var cmd = new Command("/usr/bin/nasm", args); cmd.description = "assembling (nasm) " + input.fileName; return [cmd]; } } > Alternatively, it might even suffice to do this: > cpp.targetAssemblerFlags: [] // Or put nasm-specific stuff in here, if > necessary > > No that still kept all the regular includepaths and options, didn't work. But the Rule solution works just fine. Thanks, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.courtois at gmail.com Fri Dec 15 13:55:42 2017 From: damien.courtois at gmail.com (Damien Courtois) Date: Fri, 15 Dec 2017 13:55:42 +0100 Subject: [Qbs] Fwd: qbs run --dry-run not working ? In-Reply-To: <20171215121255.24b872ae@ckandeler-archlinux> References: <20171214173807.6c36e324@ckandeler-archlinux> <20171215101520.101a3bb4@ckandeler-archlinux> <20171215121255.24b872ae@ckandeler-archlinux> Message-ID: 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 at 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 at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heiko.nardmann at itechnical.de Fri Dec 15 14:33:08 2017 From: heiko.nardmann at itechnical.de (Heiko Nardmann) Date: Fri, 15 Dec 2017 14:33:08 +0100 Subject: [Qbs] Fwd: qbs run --dry-run not working ? In-Reply-To: References: <20171214173807.6c36e324@ckandeler-archlinux> <20171215101520.101a3bb4@ckandeler-archlinux> <20171215121255.24b872ae@ckandeler-archlinux> Message-ID: <9210d72a-6dc4-1bdc-69e6-6b1f1157e590@itechnical.de> 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 at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Fri Dec 15 18:09:21 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 15 Dec 2017 17:09:21 +0000 Subject: [Qbs] Fwd: qbs run --dry-run not working ? In-Reply-To: <9210d72a-6dc4-1bdc-69e6-6b1f1157e590@itechnical.de> References: <20171214173807.6c36e324@ckandeler-archlinux> <20171215101520.101a3bb4@ckandeler-archlinux> <20171215121255.24b872ae@ckandeler-archlinux> <9210d72a-6dc4-1bdc-69e6-6b1f1157e590@itechnical.de> Message-ID: Christian, 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). > On Dec 15, 2017, at 5:33 AM, Heiko Nardmann 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 at 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 at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From elyzabethvonreuenthal at iserlohn-fortress.net Sat Dec 16 14:14:14 2017 From: elyzabethvonreuenthal at iserlohn-fortress.net (Ely) Date: Sat, 16 Dec 2017 14:14:14 +0100 Subject: [Qbs] QT_DEBUG defined on release builds Message-ID: <1598287.zLDUbR4kWK@kongou> I have a project roughly specified like this: > Project { > CppApplication { > Depends { name: "Qt.core" ... } > Group { > file: ['main.cpp'] > cpp.defines: ['SOMETHING', 'SOMETHING_ELSE'] > } > } > } With this setup, I get the following defines on a release build: > -DNDEBUG -DSOMETHING -DSOMETHING_ELSE But when the cpp.defines are not placed in a group, I get these: > -DNDEBUG -DSOMETHING -DSOMETHING_ELSE -DQT_CORE_LIB -DQT_NO_DEBUG This is a problem, because without QT_NO_DEBUG, all code in checking for QT_DEBUG compiles. I'm using qbs 1.10. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From enmarantispam at gmail.com Sat Dec 16 14:20:30 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Sat, 16 Dec 2017 16:20:30 +0300 Subject: [Qbs] QT_DEBUG defined on release builds In-Reply-To: <1598287.zLDUbR4kWK@kongou> References: <1598287.zLDUbR4kWK@kongou> Message-ID: cpp.defines: base.concat(['SOMETHING', 'SOMETHING_ELSE']) On Sat, Dec 16, 2017 at 4:14 PM, Ely < elyzabethvonreuenthal at iserlohn-fortress.net> wrote: > I have a project roughly specified like this: > > > Project { > > CppApplication { > > Depends { name: "Qt.core" ... } > > Group { > > file: ['main.cpp'] > > cpp.defines: ['SOMETHING', 'SOMETHING_ELSE'] > > } > > } > > } > > With this setup, I get the following defines on a release build: > > -DNDEBUG -DSOMETHING -DSOMETHING_ELSE > > But when the cpp.defines are not placed in a group, I get these: > > -DNDEBUG -DSOMETHING -DSOMETHING_ELSE -DQT_CORE_LIB -DQT_NO_DEBUG > > This is a problem, because without QT_NO_DEBUG, all code in checking for > QT_DEBUG compiles. > > I'm using qbs 1.10. > _______________________________________________ > 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 chgans at gmail.com Sat Dec 16 20:53:42 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Sun, 17 Dec 2017 08:53:42 +1300 Subject: [Qbs] QT_DEBUG defined on release builds In-Reply-To: References: <1598287.zLDUbR4kWK@kongou> Message-ID: On 17/12/2017 2:21 am, "NIkolai Marchenko" wrote: cpp.defines: base.concat(['SOMETHING', 'SOMETHING_ELSE']) 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, ...) The problem is that you don't get warning when you overwrite an array property, so it's easy to loose information and potentially difficult to trace. Chris. On Sat, Dec 16, 2017 at 4:14 PM, Ely wrote: > I have a project roughly specified like this: > > > Project { > > CppApplication { > > Depends { name: "Qt.core" ... } > > Group { > > file: ['main.cpp'] > > cpp.defines: ['SOMETHING', 'SOMETHING_ELSE'] > > } > > } > > } > > With this setup, I get the following defines on a release build: > > -DNDEBUG -DSOMETHING -DSOMETHING_ELSE > > But when the cpp.defines are not placed in a group, I get these: > > -DNDEBUG -DSOMETHING -DSOMETHING_ELSE -DQT_CORE_LIB -DQT_NO_DEBUG > > This is a problem, because without QT_NO_DEBUG, all code in checking for > QT_DEBUG compiles. > > I'm using qbs 1.10. > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs > > _______________________________________________ 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 chgans at gmail.com Sat Dec 16 20:56:44 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Sun, 17 Dec 2017 08:56:44 +1300 Subject: [Qbs] Qbs system settings In-Reply-To: References: <6f5b2d7d-8944-82fe-6d4e-10ed9fd7facb@gmail.com> <20171215102646.20530887@ckandeler-archlinux> Message-ID: On 15/12/2017 10:26 pm, "Christian Kandeler" wrote: On Wed, 13 Dec 2017 18:10:42 +1300 Christian Gagneraud wrote: > I would like to setup qbs profile system wide, I have tried using the > '--settings-dir' (eg qbs-setup-qt --settings-dir /etc/xdg), but then > qbs-config doesn't seem to read the system settings. > > $ /opt/qt/5.6/bin/qtpaths --paths GenericConfigLocation > /root/.config:/etc/xdg > $ /opt/qt/5.6/bin/qtpaths --paths ConfigLocation > /root/.config:/etc/xdg > > I would expect that qbs-config would see profiles defined system-wise > too. But it seems that i need to use qbs-config --settings-dir > > Can Qbs pick up build profiles defined system-wide? Looking at the source code, the answer seems to be "not reliably". We use QSettings internally, which can look up the system default, but if you give the --settings-dir option, we use a QSettings constructor which doesn't do that. So system-global settings are not really supported at the moment. You might want to file a bug report for that. Thanks for that. I'll raise a ticket as I think it's a basic but important feature. Chris Christian _______________________________________________ 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 damien.courtois at gmail.com Mon Dec 18 09:24:48 2017 From: damien.courtois at gmail.com (Damien Courtois) Date: Mon, 18 Dec 2017 09:24:48 +0100 Subject: [Qbs] Fwd: qbs run --dry-run not working ? In-Reply-To: References: <20171214173807.6c36e324@ckandeler-archlinux> <20171215101520.101a3bb4@ckandeler-archlinux> <20171215121255.24b872ae@ckandeler-archlinux> <9210d72a-6dc4-1bdc-69e6-6b1f1157e590@itechnical.de> Message-ID: > 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.nardmann at 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 at 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 at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/qbs > > -- > Jake Petroules - jake.petroules at qt.io > The Qt Company - Silicon Valley > Qbs build tool evangelist - qbs.io > > _______________________________________________ > 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 christian.kandeler at qt.io Mon Dec 18 11:21:37 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 18 Dec 2017 11:21:37 +0100 Subject: [Qbs] QT_DEBUG defined on release builds In-Reply-To: References: <1598287.zLDUbR4kWK@kongou> Message-ID: <20171218112137.1fdb3ed2@ckandeler-archlinux> 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 From enmarantispam at gmail.com Mon Dec 18 11:41:39 2017 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Mon, 18 Dec 2017 13:41:39 +0300 Subject: [Qbs] QT_DEBUG defined on release builds In-Reply-To: <20171218112137.1fdb3ed2@ckandeler-archlinux> References: <1598287.zLDUbR4kWK@kongou> <20171218112137.1fdb3ed2@ckandeler-archlinux> Message-ID: 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.kandeler at 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 at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkarel at yandex.ru Mon Dec 18 12:04:21 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Mon, 18 Dec 2017 14:04:21 +0300 Subject: [Qbs] "Multi" Properties Message-ID: <04629bdd-3bde-7563-e63b-db3c2d215ff4@yandex.ru> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Mon Dec 18 12:15:07 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Mon, 18 Dec 2017 12:15:07 +0100 Subject: [Qbs] "Multi" Properties In-Reply-To: <04629bdd-3bde-7563-e63b-db3c2d215ff4@yandex.ru> References: <04629bdd-3bde-7563-e63b-db3c2d215ff4@yandex.ru> Message-ID: <20171218121507.58a49ee8@ckandeler-archlinux> 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 From hkarel at yandex.ru Mon Dec 18 12:28:22 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Mon, 18 Dec 2017 14:28:22 +0300 Subject: [Qbs] "Multi" Properties In-Reply-To: <20171218121507.58a49ee8@ckandeler-archlinux> References: <04629bdd-3bde-7563-e63b-db3c2d215ff4@yandex.ru> <20171218121507.58a49ee8@ckandeler-archlinux> Message-ID: <84f8934a-ccf1-4fb2-7514-b0732ef8eead@yandex.ru> 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 at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From wookey at wookware.org Wed Dec 20 05:54:44 2017 From: wookey at wookware.org (Wookey) Date: Wed, 20 Dec 2017 04:54:44 +0000 Subject: [Qbs] Qbs and debian packaging Message-ID: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> I have a few things to package for Debian which use QBS. So I've had to work out how to make QBS fit into debian's build concepts and packaging mechanisms. (e.g separate build and install steps) That has gone reasonably well (although some queries about best practice remain), and I have a) a package in debian (which so far as I can tell is the first one using QBS): https://tracker.debian.org/pkg/dewalls b) a wiki page on packaging qbs-using packages for debian-style distros: https://wiki.debian.org/QBS Do please tell me what's incorrect on that page (some probably is - I claim no particular expertise). Or just fix the page. However there are things I haven't been able to make work, and quite a few queries about best practice. If QBS becomes widely-used, debian packaging tools will need to support it, and if we can make that reasonably painless for both packagers and upstreams, that is obviously good. I have more packages to do so would like to work out at least some documentation on that wiki pages with you (upstream). So the remaining issues are: 1) Properly supporting multiarch paths 2) Honouring dpkg buildflags and DEB_BUILD_OPTIONS 3) Neater way to avoid $HOME usage? 4) Crossbuilding? It might be nice to have a debian support module in QBS to make stuff 'just work'. But I don't know if this is a good plan. There may be better ways. So, in detail: Supporting multiarch -------------------- Debian puts libraries in /usr/lib/, not just /usr/lib, and not /lib64 /lib /libx32 /libilp32 etc. (You can read all about multiarch here: https://wiki.debian.org/Multiarch, it's quite a big subject) QBS does not do this by default when a debian build is detected (pehaps it could?), nor does it seem to have a 'libdir' concept that would make this an easy override. (It has an installDir which varies by type of tagged files AIUI). The correct triplet is made available to builds in $DEB_HOST_MULTIARCH, but I have not been able to work out how to read an env var inside the qbs file (is it possible?). Nor have I been able to pass a variable in, even though this should work. I should be able to do this: Project { name: package property string debHostMultiarch: "" Group { fileTagsFilter: [ "dynamiclibrary", "dynamiclibrary_symlink" ] qbs.installDir: "/usr/lib/" + debHostMultiarch qbs.install: true } then call 'qbs install' with something like this: qbs install --settings-dir /tmp --install-root debian/tmp/ profile:default debHostMultiarch:$(DEB_HOST_MULTIARCH) but I can't get this to work. Should it? What am I doing wrong? Should I set it in the profile so it is automatically available? Currently I have just used the fact that Qt.core.libPath is set to the right library path, so I can use that, but it's a hack, and only works for qt-using projects. (i.e. where module qt is loaded) There is also the issue for upstream to detect that this is a 'debian-style' build and thus should use multiarch paths. There is provision for detecting the OS, but not the distro. So perhaps it should be enabled by some kind of flag? cpp.multiarchPaths perhaps? Although I expect users would prefer it if the build system just DTRT automagically. (Similarly debian almost never wants rpath set (except plugins), and does want soVersions and dynamiclibray_symlinks so those would be good defaults too) Honouring buildflags -------------------- Debian has standard buildflags, e.g. for security settings, like hardening flags, and default optimisation. It also has a mechanism for enabling debug builds or disabling checks (e.g. for crossbuilding or when they are slow), or disabling optimisation. See https://www.debian.org/doc/debian-policy/#debian-rules-and-deb-build-options There are various ways to do this in the build process: typically some env vars are set to be used in the build, but cammands can be run instead: e.g.: CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS) https://wiki.debian.org/HardeningWalkthrough gives quite a lot of examples for different build systems. I have not managed to make these work as I don't know if there is a machanism to use env vars in qbs files. Is there? If not, how should such info be passed in? Would we need to make equivalent qbs strings/lists? Also I haven't worked out the 'precedence rules' for QBS. i.e if cpp.cxxFlags is set in the qbs file, and passed in via a qbs command, does the latter take precedence? Is there a syntax for += (i.e. add these options to the existing list) ? qbs tried to avoid this sticky area of setting flags, because they are toolchain specific, which makes sense, but we need a way of setting a specific set of things. The current dpkg-buildflags is: CFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security FCFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong FFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security Does it make sense to add generic qbs names for all those things? What happens when debian changes to a different set of options? If not, how do we let qbs set what the package asks for (e.g. via cpp.cLanguageVersion) whilst also honouring the required debian build options? we already have cpp.optimization (grr, US spellings!) and cpp.debugInformation and the various cpp.cxxFlags etc. but no hardening options. So I have no real idea how best to do this. Advice welcome. Avoiding $HOME use ------------------ Debian buildds do not have $HOME available, because per-user data should not affect package builds. qbs defaults to storing settings/profiles in $HOME/.config/QtProject/qbs so that simply doesn't work. Using the --settings-dir option to make it use another dir does the trick but is a bit clumsy as it has to be done on every command. If there was an env var to set which would override this, that would be rather neater. Is there such a thing? Might you consider adding it? Crossbuilding ------------- Does QBS support this, or is it intended to support this? I've not tried yet. Setting the right toolchain commands: -gcc, -binutils, -strip, etc is a good start. config ------ I do have some other questions about the initial profile setup, but this mail is long enough already, so lets leave that for now. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From christian.kandeler at qt.io Wed Dec 20 11:09:01 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 20 Dec 2017 11:09:01 +0100 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> Message-ID: <20171220110901.6135f7a3@ckandeler-archlinux> On Wed, 20 Dec 2017 04:54:44 +0000 Wookey wrote: > I have a few things to package for Debian which use QBS. > > So I've had to work out how to make QBS fit into debian's build > concepts and packaging mechanisms. (e.g separate build and install steps) > > That has gone reasonably well (although some queries about best > practice remain), and I have > a) a package in debian (which so far as I can tell is the first one using QBS): > https://tracker.debian.org/pkg/dewalls I'm having trouble locating the actual project sources. Can you point me to them? > b) a wiki page on packaging qbs-using packages for debian-style distros: > https://wiki.debian.org/QBS > > Do please tell me what's incorrect on that page (some probably is - I > claim no particular expertise). Or just fix the page. Here are my comments on the wiki page. - Regarding the separation of build and install steps: 1) Even when not installing during the build, the install root should still be passed: qbs build --no-install modules.qbs.installRoot:. 2) I suggest passing the --no-build flag to the install command, for extra safety. - From (I think) qbs 1.9 on the profile no longer determines the name of the build directory. Instead, there is now the concept of a "configuration". Until (and including) qbs 1.10, this name is (unfortunately) given as a simple context-less parameter, like this: $ qbs build default // Same as "qbs build", dir is named "default" $ qbs build myConfig // dir is named "myConfig" From qbs 1.11 onwards, there will be a more sensible syntax: $ qbs build config:myConfig - Regarding the setup: As you have noticed, the current approach to storing/reading settings does not really consider anything but a "normal user". It'd be great if you could create a task at bugreports.qt.io and tell us more about your requirements. - I find this sentence a bit misleading: "qbs is usually used with Qt although in principle it could work for other projects." It might be statistically true at this point, but the wording seems to imply that using it for non-Qt projects is purely a theoretical thing, which is really not the case. I'd prefer something like "qbs is often used for Qt projects, in which case the path to qmake [...]" - Regarding the lib paths: I suppose something along the lines of what you show there is the correct approach, though I would not necessarily expect project authors to provide debian-specific hooks, but rather generic ones. For instance: Project { // Or in some project-specific module property string libDir: "lib" // ... } DynamicLibrary { Group { fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink"] qbs.install: true qbs.installDir: project.libDir } } $ qbs build project.libDir:lib/$DEB_HOST_MULTIARCH Note that "usr" should probably not be part of qbs.installDir, but rather is a possible value of qbs.installPrefix. - Environment variables can be read with Environment.getEnv(). See https://doc.qt.io/qbs/jsextension-environment.html. - Setting cpp.cxxFlags on the command line should work. Note that your example has a typo (cxxflags with a lower-case f). If that's how you entered it, that would explain why it didn't work (though you should have gotten a warning). > It might be nice to have a debian support module in QBS to make stuff > 'just work'. https://bugreports.qt.io/browse/QBS-417 You might want to add suggestions there. > Supporting multiarch I think I have addressed most of these above. If anything is still unclear, does not work or you simply disagree, please tell me. > There is also the issue for upstream to detect that this is a > 'debian-style' build and thus should use multiarch paths. There is > provision for detecting the OS, but not the distro. So perhaps it > should be enabled by some kind of flag? cpp.multiarchPaths perhaps? > Although I expect users would prefer it if the build system just DTRT > automagically. (Similarly debian almost never wants rpath set (except > plugins), and does want soVersions and dynamiclibray_symlinks so those > would be good defaults too) I would have thought that this sort of package-specific configuration was the job of the debian rules file. Am I wrong? > Honouring buildflags > -------------------- > > Debian has standard buildflags, e.g. for security settings, like > hardening flags, and default optimisation. It also has a mechanism for > enabling debug builds or disabling checks (e.g. for crossbuilding or > when they are slow), or disabling optimisation. See > https://www.debian.org/doc/debian-policy/#debian-rules-and-deb-build-options > > There are various ways to do this in the build process: typically > some env vars are set to be used in the build, but cammands can be run instead: > e.g.: CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS) > > https://wiki.debian.org/HardeningWalkthrough gives quite a lot of > examples for different build systems. > > I have not managed to make these work as I don't know if there is a > machanism to use env vars in qbs files. Is there? If not, how should > such info be passed in? Would we need to make equivalent qbs strings/lists? I have mentioned above how to get at environment variables, but unless we are talking about a specific debian module in qbs (see the linked task above), this looks like it's the wrong way around. Why not just pass the flags on the command line or put them in some sort of "packaging profile", e.g. via the qbs config command? > Also I haven't worked out the 'precedence rules' for QBS. i.e if > cpp.cxxFlags is set in the qbs file, and passed in via a qbs command, > does the latter take precedence? Is there a syntax for += (i.e. add > these options to the existing list) ? The precendence for module properties in decreasing order: - command line - project files - profiles - module prototype (i.e. the default values from the module file) Regarding the list semantics: Command-line overrides wipe out everything else (we might want to think about making that configurable), but in all other contexts lists are merged. In particular, profile contents simply replace the default values from the module prototype and thus get merged with what's in the project files. The latter is probably what you want. > qbs tried to avoid this sticky area of setting flags, because they are > toolchain specific, which makes sense, but we need a way of setting a specific set of things. The current dpkg-buildflags is: > CFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security "-g" -> cpp.debugInformation:true "-O2" -> cpp.optimization:fast The rest would go into cpp.cFlags. > CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 "-D" -> cpp.defines The rest would go into cpp.commonCompilerFlags. > CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security cpp.cxxFlags for the "rest". > FCFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong > FFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong This is for Fortran? We have no fortran module yet. > GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong Is gcj of any relevance these days? > LDFLAGS=-Wl,-z,relro cpp.linkerFlags, but without the "-Wl," escape. > OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security cpp.objcFlags for the "rest". > OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security cpp.objcxxFlags for the "rest". > Does it make sense to add generic qbs names for all those things? No, I don't think so (in general; I have not evaluated all of the flags). We introduce convenience properties whenever there is a sensible abstraction that maps to different options on different compilers/linkers. > What happens when debian changes to a different set of options? Again, I was under the impression that it would be the packaging process' job to provide the correct set of flags to the build tool. > If not, how do we let qbs set what the package asks for (e.g. via > cpp.cLanguageVersion) whilst also honouring the required debian build > options? Not sure what you mean here. There should not be any conflicts. > Avoiding $HOME use Also commented on above. > Crossbuilding > ------------- > > Does QBS support this, or is it intended to support this? I've not > tried yet. Setting the right toolchain commands: -gcc, > -binutils, -strip, etc is a good start. There is nothing special about crossbuilding. Historically, the target architecture has been determined by the setup-toolchain command, but recently qbs has shifted more and more to being self-contained in this regard. Setting cpp.toolchainInstallPath, cpp.toolchainPrefix and qbs.sysroot should generally be enough. Christian From wookey at wookware.org Wed Dec 20 14:02:22 2017 From: wookey at wookware.org (Wookey) Date: Wed, 20 Dec 2017 13:02:22 +0000 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171220110901.6135f7a3@ckandeler-archlinux> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> Message-ID: <20171220130221.dqzah6mzxhocjsfy@mail.wookware.org> On 2017-12-20 11:09 +0100, Christian Kandeler wrote: > On Wed, 20 Dec 2017 04:54:44 +0000 > Wookey wrote: > > > I have a few things to package for Debian which use QBS. > > > > So I've had to work out how to make QBS fit into debian's build > > concepts and packaging mechanisms. (e.g separate build and install steps) > > > > That has gone reasonably well (although some queries about best > > practice remain), and I have > > a) a package in debian (which so far as I can tell is the first one using QBS): > > https://tracker.debian.org/pkg/dewalls > > I'm having trouble locating the actual project sources. Can you point me to them? You can view it here: https://sources.debian.org/src/dewalls/1.0.0+ds1-2/ or download the source here: http://deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1-2.dsc dget will pull all 3 files, or download the tarball and diff manually as well: http://cdn-fastly.deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1.orig.tar.gz http://cdn-fastly.deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1-2.debian.tar.xz > Here are my comments on the wiki page. > - Regarding the separation of build and install steps: > 1) Even when not installing during the build, the install root should > still be passed: qbs build --no-install modules.qbs.installRoot:. Could you elaborate on why? rpaths is the only thing I can think of that would be affected (if not actually installing) and we don't want those pointing to temporary install directories. > 2) I suggest passing the --no-build flag to the install command, for > extra safety. > - From (I think) qbs 1.9 on the profile no longer determines the name of the > build directory. Instead, there is now the concept of a "configuration". > Until (and including) qbs 1.10, this name is (unfortunately) given as > a simple context-less parameter, like this: > $ qbs build default // Same as "qbs build", dir is named "default" > $ qbs build myConfig // dir is named "myConfig" > From qbs 1.11 onwards, there will be a more sensible syntax: > $ qbs build config:myConfig > - Regarding the setup: As you have noticed, the current approach to > storing/reading settings does not really consider anything but a > "normal user". It'd be great if you could create a task at > bugreports.qt.io and tell us more about your requirements. Will do. > - I find this sentence a bit misleading: "qbs is usually used with > Qt although in principle it could work for other projects." It might > be statistically true at this point, but the wording seems to imply > that using it for non-Qt projects is purely a theoretical thing, > which is really not the case. I'd prefer something like "qbs is often > used for Qt projects, in which case the path to qmake [...]" OK. I wasn't quite sure to what degree it is intended to be a general-purpose build system, especially for languages other than C/C++/ObjC Thanks for reading the page and making comprehensive comments. > - Regarding the lib paths: I suppose something along the lines of what > you show there is the correct approach, though I would not necessarily > expect project authors to provide debian-specific hooks, but rather > generic ones. For instance: > Project { // Or in some project-specific module > property string libDir: "lib" > // ... > } > DynamicLibrary { > Group { > fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink"] > qbs.install: true > qbs.installDir: project.libDir > } > } > $ qbs build project.libDir:lib/$DEB_HOST_MULTIARCH Good point. > Note that "usr" should probably not be part of qbs.installDir, but > rather is a possible value of qbs.installPrefix. > - Environment variables can be read with Environment.getEnv(). > See https://doc.qt.io/qbs/jsextension-environment.html. > - Setting cpp.cxxFlags on the command line should work. Note that your > example has a typo (cxxflags with a lower-case f). If that's how > you entered it, that would explain why it didn't work (though you > should have gotten a warning). > > > It might be nice to have a debian support module in QBS to make stuff > > 'just work'. > > https://bugreports.qt.io/browse/QBS-417 > You might want to add suggestions there. > > > Supporting multiarch > > I think I have addressed most of these above. If anything is still unclear, does not work or you simply disagree, please tell me. > > > There is also the issue for upstream to detect that this is a > > 'debian-style' build and thus should use multiarch paths. There is > > provision for detecting the OS, but not the distro. So perhaps it > > should be enabled by some kind of flag? cpp.multiarchPaths perhaps? > > Although I expect users would prefer it if the build system just DTRT > > automagically. (Similarly debian almost never wants rpath set (except > > plugins), and does want soVersions and dynamiclibray_symlinks so those > > would be good defaults too) > > I would have thought that this sort of package-specific configuration was the job of the debian rules file. Am I wrong? That's a somewhat philosophical question. Ultimately, yes, all such details are for the packaging to get right, but it's good if the upstream build does as much as reasonable 'right'. To what degree does a user expect to get a 'bare upstream' build, or one built for the OS/distro that they are running on? I'm not quite sure what the QBS philosophy is here. It looks to me like it changes binary and library paths automatically to suit the OS, so QBS knowing about multiarch and using it when appropriate makes sense in this context. (Hopefully it will become a sensible default on linux eventually, but currently only debian-style distros use it by default. The main impediment to wider adoption is the lack of a distro-independent mechanism for finding canonical triplets for ABIs). On the other hand too much invisible magic can be confusing and more explicitly specifying things makes it clearer what is going on. On rpaths QBS presumably needs to make heavy use for its 'local install' mechanism to work, so wants to default them on. > > Honouring buildflags > > -------------------- > > > > Debian has standard buildflags, e.g. for security settings, like > > hardening flags, and default optimisation. It also has a mechanism for > > enabling debug builds or disabling checks (e.g. for crossbuilding or > > when they are slow), or disabling optimisation. See > > https://www.debian.org/doc/debian-policy/#debian-rules-and-deb-build-options > > > > There are various ways to do this in the build process: typically > > some env vars are set to be used in the build, but cammands can be run instead: > > e.g.: CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS) > > > > https://wiki.debian.org/HardeningWalkthrough gives quite a lot of > > examples for different build systems. > > > > I have not managed to make these work as I don't know if there is a > > machanism to use env vars in qbs files. Is there? If not, how should > > such info be passed in? Would we need to make equivalent qbs strings/lists? > > I have mentioned above how to get at environment variables, but unless we are talking about a specific debian module in qbs (see the linked task above), this looks like it's the wrong way around. Why not just pass the flags on the command line or put them in some sort of "packaging profile", e.g. via the qbs config command? If the upstream .qbs file does not overwrite passed-in variables, then yes just passing them in should work (and makes qbs behave like other build systems). This was not working for me, (the dewalls .qbs file sets cpp.cxxFlags and cpp.linkerFlags) which is why I asked about precedence an appending rules. I'll experiment some more. (As you say - maybe I just typoed the variable name.) > > Also I haven't worked out the 'precedence rules' for QBS. i.e if > > cpp.cxxFlags is set in the qbs file, and passed in via a qbs command, > > does the latter take precedence? Is there a syntax for += (i.e. add > > these options to the existing list) ? > > The precendence for module properties in decreasing order: > - command line > - project files > - profiles > - module prototype (i.e. the default values from the module file) > Regarding the list semantics: Command-line overrides wipe out everything else (we might want to think about making that configurable), but in all other contexts lists are merged. In particular, profile contents simply replace the default values from the module prototype and thus get merged with what's in the project files. The latter is probably what you want. Yes, that sounds promising. > > qbs tried to avoid this sticky area of setting flags, because they are > > toolchain specific, which makes sense, but we need a way of setting a specific set of things. The current dpkg-buildflags is: > > CFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security > > "-g" -> cpp.debugInformation:true > "-O2" -> cpp.optimization:fast > The rest would go into cpp.cFlags. > > > CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 > > "-D" -> cpp.defines > The rest would go into cpp.commonCompilerFlags. > > > CXXFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security > > cpp.cxxFlags for the "rest". > > > FCFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong > > FFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong > > This is for Fortran? We have no fortran module yet. > > > GCJFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong > > Is gcj of any relevance these days? > > > LDFLAGS=-Wl,-z,relro > > cpp.linkerFlags, but without the "-Wl," escape. > > > OBJCFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security > > cpp.objcFlags for the "rest". > > > OBJCXXFLAGS=-g -O2 -fdebug-prefix-map=/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0=. -fstack-protector-strong -Wformat -Werror=format-security > > cpp.objcxxFlags for the "rest". > > > Does it make sense to add generic qbs names for all those things? > > No, I don't think so (in general; I have not evaluated all of the flags). We introduce convenience properties whenever there is a sensible abstraction that maps to different options on different compilers/linkers. > > > What happens when debian changes to a different set of options? > > Again, I was under the impression that it would be the packaging process' job to provide the correct set of flags to the build tool. > > > If not, how do we let qbs set what the package asks for (e.g. via > > cpp.cLanguageVersion) whilst also honouring the required debian build > > options? > > Not sure what you mean here. There should not be any conflicts. > > > Avoiding $HOME use > > Also commented on above. > > > Crossbuilding > > ------------- > > > > Does QBS support this, or is it intended to support this? I've not > > tried yet. Setting the right toolchain commands: -gcc, > > -binutils, -strip, etc is a good start. > > There is nothing special about crossbuilding. Historically, the target architecture has been determined by the setup-toolchain command, but recently qbs has shifted more and more to being self-contained in this regard. Setting cpp.toolchainInstallPath, cpp.toolchainPrefix and qbs.sysroot should generally be enough. I agree there is nothing very special about crossbuilding, but build systems (especially new ones) regularly make assumptions that make it difficult to have it working right :-) I was wondering if the qbs-toolchain=setup --detect would interact badly with crossing, for example, and how the packaging should indicate the (build and) host architecture(s). Thanks for the pointers. I'll test. In debian only cpp.toolchainPrefix should be needed. Because of multiarch, there is no sysroot (or one can consider it to be '/'). and crosstoolchains are installed in the same paths as native toolchains. (although it remains possible to use an external toolchain and sysroot if desired, which should all fit quite nicely into this mechanism). Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From damien.courtois at gmail.com Wed Dec 20 14:57:25 2017 From: damien.courtois at gmail.com (Damien Courtois) Date: Wed, 20 Dec 2017 14:57:25 +0100 Subject: [Qbs] Fwd: qbs run --dry-run not working ? In-Reply-To: References: <20171214173807.6c36e324@ckandeler-archlinux> <20171215101520.101a3bb4@ckandeler-archlinux> <20171215121255.24b872ae@ckandeler-archlinux> <9210d72a-6dc4-1bdc-69e6-6b1f1157e590@itechnical.de> Message-ID: Hi again, sorry to resurrect this thread, but I'd like to know if there is a chance to see a "server mode" coming to qbs command line tool ? If so, is there a place where a feature request could be posted and tracked ? And if not, would it be feasible / would it make sense to make --dry-run also disable running the product, or add a new flag to do that ? This simple modification would allow me to parse the output and get the path to the final product thanks to the log "Starting target '...'." 2017-12-18 9:24 GMT+01:00 Damien Courtois : > > 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.nardmann at 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 < >> christian.kandeler at qt.io>: >> >> 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 at 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 at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/qbs >> >> -- >> Jake Petroules - jake.petroules at qt.io >> The Qt Company - Silicon Valley >> Qbs build tool evangelist - qbs.io >> >> _______________________________________________ >> 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 christian.kandeler at qt.io Wed Dec 20 15:13:24 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 20 Dec 2017 15:13:24 +0100 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171220130221.dqzah6mzxhocjsfy@mail.wookware.org> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> <20171220130221.dqzah6mzxhocjsfy@mail.wookware.org> Message-ID: <20171220151324.2e654dfc@ckandeler-archlinux> On Wed, 20 Dec 2017 13:02:22 +0000 Wookey wrote: > > I'm having trouble locating the actual project sources. Can you point me to them? > > You can view it here: > https://sources.debian.org/src/dewalls/1.0.0+ds1-2/ > or download the source here: > http://deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1-2.dsc > dget will pull all 3 files, or download the tarball and diff manually as well: > http://cdn-fastly.deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1.orig.tar.gz > http://cdn-fastly.deb.debian.org/debian/pool/main/d/dewalls/dewalls_1.0.0+ds1-2.debian.tar.xz Thanks. Apparently, the project author is not aware of the convenience properties in the cpp module; the project file could be much shorter and easier to read if they had been used. Also, "cpp.installNamePrefix: qbs.installRoot" looks very suspicious. > > Here are my comments on the wiki page. > > - Regarding the separation of build and install steps: > > 1) Even when not installing during the build, the install root should > > still be passed: qbs build --no-install modules.qbs.installRoot:. > > Could you elaborate on why? rpaths is the only thing I can think of > that would be affected (if not actually installing) and we don't want > those pointing to temporary install directories. In a correctly written project, nothing will ever refer to qbs.installRoot in a way that this value ends up permanently in some binary. However, it is conceivable that there is, for instance, some sort of packaging rule that picks up artifacts from there. In short, the value that qbs thinks the install root is during the build should be the one used when installing, if only for conceptual correctness. > OK. I wasn't quite sure to what degree it is intended to be a > general-purpose build system, especially for languages other than > C/C++/ObjC It is. There is not much support for other languages at the moment, but modules for those can easily be added when there's interest. > Thanks for reading the page and making comprehensive comments. Thanks for writing it ;) > > > There is also the issue for upstream to detect that this is a > > > 'debian-style' build and thus should use multiarch paths. There is > > > provision for detecting the OS, but not the distro. So perhaps it > > > should be enabled by some kind of flag? cpp.multiarchPaths perhaps? > > > Although I expect users would prefer it if the build system just DTRT > > > automagically. (Similarly debian almost never wants rpath set (except > > > plugins), and does want soVersions and dynamiclibray_symlinks so those > > > would be good defaults too) > > > > I would have thought that this sort of package-specific configuration was the job of the debian rules file. Am I wrong? > > That's a somewhat philosophical question. Ultimately, yes, all such > details are for the packaging to get right, but it's good if the > upstream build does as much as reasonable 'right'. To what degree does > a user expect to get a 'bare upstream' build, or one built for the > OS/distro that they are running on? > I'm not quite sure what the QBS philosophy is here. Admittedly I have personally not spent much time thinking about this, but my gut feeling would rather be not to be distribution-aware. We'd have to keep up with their (possibly changing) conventions, for one. > On rpaths QBS presumably needs to make heavy use for its 'local > install' mechanism to work, so wants to default them on. Right. But they can be easily disabled using cpp.useRPaths. > > > Crossbuilding > > > ------------- > > > > > > Does QBS support this, or is it intended to support this? I've not > > > tried yet. Setting the right toolchain commands: -gcc, > > > -binutils, -strip, etc is a good start. > > > > There is nothing special about crossbuilding. Historically, the target architecture has been determined by the setup-toolchain command, but recently qbs has shifted more and more to being self-contained in this regard. Setting cpp.toolchainInstallPath, cpp.toolchainPrefix and qbs.sysroot should generally be enough. > > I agree there is nothing very special about crossbuilding, but build > systems (especially new ones) regularly make assumptions that make it > difficult to have it working right :-) I'm surprised to hear that. One would think that the "host == target" assumption would long be gone. In fact, for qbs, in a way that is the special case, rather than the other way around. Christian From wookey at wookware.org Thu Dec 21 03:25:24 2017 From: wookey at wookware.org (Wookey) Date: Thu, 21 Dec 2017 02:25:24 +0000 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171220151324.2e654dfc@ckandeler-archlinux> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> <20171220130221.dqzah6mzxhocjsfy@mail.wookware.org> <20171220151324.2e654dfc@ckandeler-archlinux> Message-ID: <20171221022524.zqrsmph67fywkkc7@mail.wookware.org> On 2017-12-20 15:13 +0100, Christian Kandeler wrote: > On Wed, 20 Dec 2017 13:02:22 +0000 > Wookey wrote: > > Thanks. Apparently, the project author is not aware of the convenience > properties in the cpp module; the project file could be much shorter and easier to read if they had been used. Yes. To be fair I think they were a very early qbs adopter and fewer existed (e.g. cpp.cxxLanguageVersion) The debian patches (in debian/patches) change the dewalls.qbs file to use these. > Also, "cpp.installNamePrefix: qbs.installRoot" looks very suspicious. yes. that is nobbled in the debian patches too. Dewalls upstream is aware of these changes and will update. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From wookey at wookware.org Thu Dec 21 05:35:34 2017 From: wookey at wookware.org (Wookey) Date: Thu, 21 Dec 2017 04:35:34 +0000 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171220110901.6135f7a3@ckandeler-archlinux> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> Message-ID: <20171221043534.v6k4sbeeadmvndrm@mail.wookware.org> On 2017-12-20 11:09 +0100, Christian Kandeler wrote: > On Wed, 20 Dec 2017 04:54:44 +0000 > Wookey wrote: > > > b) a wiki page on packaging qbs-using packages for debian-style distros: > > https://wiki.debian.org/QBS > > > > Do please tell me what's incorrect on that page [snip comments] OK. Page updated, although there will be more when this conversation is finished. You suggested > qbs build --no-install modules.qbs.installRoot:debian/tmp > qbs install --no-build modules.qbs.installRoot:debian/tmp However this breaks the build, because nothing gets installed into debian/tmp. But this works > qbs build --no-install modules.qbs.installRoot:debian/tmp > qbs install --no-build --install-root debian/tmp I had assumed that --install-root and modules.qbs.installRoot were equivalent, but it seems they are not. Is this expected? The main difference seems to be that --install-root creates the directory if it doesn't exist? > - Regarding the lib paths: I suppose something along the lines of what > you show there is the correct approach, though I would not necessarily > expect project authors to provide debian-specific hooks, but rather > generic ones. For instance: > Project { // Or in some project-specific module > property string libDir: "lib" > // ... > } > DynamicLibrary { > Group { > fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink"] > qbs.install: true > qbs.installDir: project.libDir > } > } > $ qbs build project.libDir:lib/$DEB_HOST_MULTIARCH OK. this works, and I agree that a generic name is better. > Note that "usr" should probably not be part of qbs.installDir, but > rather is a possible value of qbs.installPrefix. This works if done on the command line: qbs install modules.qbs.installPrefix:usr/ project.libDir:lib/$DEB_HOST_MULTIARCH but not if either variable is set in the profile. They are ignored: qbs config --settings-dir /tmp modules.qbs.installPrefix usr/ Ah, the namespace was wrong, it should be: qbs config --settings-dir /tmp profiles.default.qbs.installPrefix usr/ but using qbs config --settings-dir /tmp profiles.default.project.libDir lib/$(DEB_HOST_MULTIARCH) does not work because the property string libDir: "lib" in the project file overwrites it unless that var is set on the command line. Right? I'm confused about the namespacing. It seems to be different for the build/install commands and the config command: qbs config profiles.default.cpp.linkerFlags "-z,relro" qbs build modules.cpp.linkerFlags:"-z,relro" both set the linker flags in the build. I can see why there is the "profiles.default" namespace in the config command, but why does one have 'modules' in and not the other? qbs config profiles.default.modules.cpp.linkerFlags "-z,relro" does not change the linkerFlags in the build. Also I note that '=' in the config vlaue seems to cause a problem: qbs config profiles.default.cpp.defines "FORTIFY_SOURCE=2" does not cause -DFORTIFY_SOURCE=2 in the build, it causes -D2 Ah. OK it needs to be suplied as a quoted list: qbs config profiles.default.cpp.defines '[ "FORTIFY_SOURCE=2" ]' > > Honouring buildflags > > -------------------- > > > Why not just pass the flags on the command line or put them in some sort of "packaging profile", e.g. via the qbs config command? So I have done this, and once I worked out namespace and quoting issues it works. The only problem is that a lot on string-munging is required to convert: CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security LDFLAGS=-Wl,-z,relro into qbs config --settings-dir /tmp profiles.default.cpp.debugInformation true qbs config --settings-dir /tmp profiles.default.cpp.optimization fast qbs config --settings-dir /tmp profiles.default.cpp.commonCompilerFlags -Wdate-time qbs config --settings-dir /tmp profiles.default.cpp.defines '[ "FORTIFY_SOURCE=2" ]' qbs config --settings-dir /tmp profiles.default.cpp.cFlags '[ "-fstack-protector-strong", "-Wformat", "-Werror=format-security" ]' qbs config --settings-dir /tmp profiles.default.cpp.cxxFlags '[ "-fstack-protector-strong", "-Wformat" "-Werror=format-security" ]' qbs config --settings-dir /tmp profiles.default.cpp.linkerFlags "-z,relro" So I can do this for a static config of current build flags, but some work would be involved in automating this so that it still worked when the flags changed (they do from time to time, and can be changed per-user, per-system etc). We wouldn't want every debian rules file to have to have a lot of boilerplate for this conversion. A debian qbs module could presumably do the necesary munging. The dpkg-buildflags interface is quite flexible and can select items by 'area' (reproducible, hardening, qa, sanitize) and vendor/system/user/env and understands prepending and appending and setting and removing, but currently output formats are shell, cmdline and make, so a new one for qbs would be needed for painless support, and teaching it that defines might be wanted without the -D, or linker options without the -Wl would be new. I'll discuss this with the dpkg maintainers. So, I think I have made everything work (except DEB_BUILD_OPTIONS - I'll try that tomorrow), but only for the static case. And there are a few clarifications requested above. Then I can update the wiki. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Jake.Petroules at qt.io Thu Dec 21 06:47:14 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 21 Dec 2017 05:47:14 +0000 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171221043534.v6k4sbeeadmvndrm@mail.wookware.org> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> <20171221043534.v6k4sbeeadmvndrm@mail.wookware.org> Message-ID: <10095EB0-42BB-4F74-9CD1-7212C05188C1@qt.io> "Qbs requires a 'toolchain setup' phase..." This is still possible in 1.9 and 1.10, but is effectively no longer *required* as Qbs will detect all that information automatically. I'd rewrite that section or otherwise just remove it entirely since you already talk about profiles. I will probably aim to remove setup-toolchains entirely after a few more things get done. However, setup-qt is still necessary when using Qt, for the time being. > On Dec 20, 2017, at 8:35 PM, Wookey wrote: > > On 2017-12-20 11:09 +0100, Christian Kandeler wrote: >> On Wed, 20 Dec 2017 04:54:44 +0000 >> Wookey wrote: >> >>> b) a wiki page on packaging qbs-using packages for debian-style distros: >>> https://wiki.debian.org/QBS >>> >>> Do please tell me what's incorrect on that page > > [snip comments] > > OK. Page updated, although there will be more when this conversation is finished. > > You suggested >> qbs build --no-install modules.qbs.installRoot:debian/tmp >> qbs install --no-build modules.qbs.installRoot:debian/tmp > However this breaks the build, because nothing gets installed into debian/tmp. > > But this works >> qbs build --no-install modules.qbs.installRoot:debian/tmp >> qbs install --no-build --install-root debian/tmp > > I had assumed that --install-root and modules.qbs.installRoot were > equivalent, but it seems they are not. Is this expected? The main > difference seems to be that --install-root creates the directory if it > doesn't exist? > >> - Regarding the lib paths: I suppose something along the lines of what >> you show there is the correct approach, though I would not necessarily >> expect project authors to provide debian-specific hooks, but rather >> generic ones. For instance: >> Project { // Or in some project-specific module >> property string libDir: "lib" >> // ... >> } >> DynamicLibrary { >> Group { >> fileTagsFilter: ["dynamiclibrary", "dynamiclibrary_symlink"] >> qbs.install: true >> qbs.installDir: project.libDir >> } >> } >> $ qbs build project.libDir:lib/$DEB_HOST_MULTIARCH > > OK. this works, and I agree that a generic name is better. > >> Note that "usr" should probably not be part of qbs.installDir, but >> rather is a possible value of qbs.installPrefix. > > This works if done on the command line: > qbs install modules.qbs.installPrefix:usr/ project.libDir:lib/$DEB_HOST_MULTIARCH > > but not if either variable is set in the profile. They are ignored: > qbs config --settings-dir /tmp modules.qbs.installPrefix usr/ > > > > Ah, the namespace was wrong, it should be: > qbs config --settings-dir /tmp profiles.default.qbs.installPrefix usr/ > but using > qbs config --settings-dir /tmp profiles.default.project.libDir lib/$(DEB_HOST_MULTIARCH) > does not work because the > property string libDir: "lib" > in the project file overwrites it unless that var is set on the command line. Right? > > I'm confused about the namespacing. It seems to be different for the > build/install commands and the config command: > qbs config profiles.default.cpp.linkerFlags "-z,relro" > qbs build modules.cpp.linkerFlags:"-z,relro" > > both set the linker flags in the build. I can see why there is the > "profiles.default" namespace in the config command, but why does one > have 'modules' in and not the other? > qbs config profiles.default.modules.cpp.linkerFlags "-z,relro" > does not change the linkerFlags in the build. > > Also I note that '=' in the config vlaue seems to cause a problem: > qbs config profiles.default.cpp.defines "FORTIFY_SOURCE=2" > does not cause -DFORTIFY_SOURCE=2 in the build, it causes -D2 > Ah. OK it needs to be suplied as a quoted list: > qbs config profiles.default.cpp.defines '[ "FORTIFY_SOURCE=2" ]' > >>> Honouring buildflags >>> -------------------- >>> > >> Why not just pass the flags on the command line or put them in some sort of "packaging profile", e.g. via the qbs config command? > > So I have done this, and once I worked out namespace and quoting issues it works. > > The only problem is that a lot on string-munging is required to convert: > > CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security > CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 > CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security > LDFLAGS=-Wl,-z,relro > into > qbs config --settings-dir /tmp profiles.default.cpp.debugInformation true > qbs config --settings-dir /tmp profiles.default.cpp.optimization fast > qbs config --settings-dir /tmp profiles.default.cpp.commonCompilerFlags -Wdate-time > qbs config --settings-dir /tmp profiles.default.cpp.defines '[ "FORTIFY_SOURCE=2" ]' > qbs config --settings-dir /tmp profiles.default.cpp.cFlags '[ "-fstack-protector-strong", "-Wformat", "-Werror=format-security" ]' > qbs config --settings-dir /tmp profiles.default.cpp.cxxFlags '[ "-fstack-protector-strong", "-Wformat" "-Werror=format-security" ]' > qbs config --settings-dir /tmp profiles.default.cpp.linkerFlags "-z,relro" > > So I can do this for a static config of current build flags, but some > work would be involved in automating this so that it still worked when > the flags changed (they do from time to time, and can be changed > per-user, per-system etc). We wouldn't want every debian rules file to > have to have a lot of boilerplate for this conversion. > > A debian qbs module could presumably do the necesary munging. > > The dpkg-buildflags interface is quite flexible and can select items > by 'area' (reproducible, hardening, qa, sanitize) and > vendor/system/user/env and understands prepending and appending and > setting and removing, but currently output formats are shell, cmdline > and make, so a new one for qbs would be needed for painless support, > and teaching it that defines might be wanted without the -D, or linker > options without the -Wl would be new. > > I'll discuss this with the dpkg maintainers. > > So, I think I have made everything work (except DEB_BUILD_OPTIONS - > I'll try that tomorrow), but only for the static case. And there are a > few clarifications requested above. Then I can update the wiki. > > Wookey > -- > Principal hats: Linaro, Debian, Wookware, ARM > http://wookware.org/ > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From christian.kandeler at qt.io Thu Dec 21 09:40:36 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 21 Dec 2017 09:40:36 +0100 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171221043534.v6k4sbeeadmvndrm@mail.wookware.org> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> <20171221043534.v6k4sbeeadmvndrm@mail.wookware.org> Message-ID: <20171221094036.12f6a214@ckandeler-archlinux> On Thu, 21 Dec 2017 04:35:34 +0000 Wookey wrote: > You suggested > > qbs build --no-install modules.qbs.installRoot:debian/tmp > > qbs install --no-build modules.qbs.installRoot:debian/tmp > However this breaks the build, because nothing gets installed into debian/tmp. Works for me. Which version of qbs is this? You should pass in an absolute path, by the way, e.g.: $ qbs build --no-install modules.qbs.installRoot:$PWD/debian/tmp Also note that from qbs 1.9 on, you don't have to repeat any of the properties on subsequent qbs invocations, as the values are stored in the build graph. > I'm confused about the namespacing. It seems to be different for the > build/install commands and the config command: > qbs config profiles.default.cpp.linkerFlags "-z,relro" > qbs build modules.cpp.linkerFlags:"-z,relro" > > both set the linker flags in the build. I can see why there is the > "profiles.default" namespace in the config command, but why does one > have 'modules' in and not the other? > qbs config profiles.default.modules.cpp.linkerFlags "-z,relro" > does not change the linkerFlags in the build. On the command line you can set all kinds of properties: $ qbs modules.mymodule.property:value $ qbs products.myproduct.property:value $ qbs projects.myproject.property:value Since projects and products, for instance, have their own namespace, there could be ambiguities otherwise: $ qbs p.property:value // Oops, there is a project named "p" and also a product (or module)! Profiles, on the other hand, are intended to be used across different projects and can therefore not set project and product properties, so no disambiguation is necessary. > Also I note that '=' in the config vlaue seems to cause a problem: > qbs config profiles.default.cpp.defines "FORTIFY_SOURCE=2" > does not cause -DFORTIFY_SOURCE=2 in the build, it causes -D2 > Ah. OK it needs to be suplied as a quoted list: > qbs config profiles.default.cpp.defines '[ "FORTIFY_SOURCE=2" ]' Or: $ qbs config profiles.default.cpp.defines '"FORTIFY_SOURCE=2"' You just needed double-quoting there for it to to still be a string after shell expansion. In general, our command-line tools allow full JS syntax as well as simple strings for less verbosity, to simplify the normal case where no special characters are involved. Lists can also be specified in CSV format in that case. > > Why not just pass the flags on the command line or put them in some sort of "packaging profile", e.g. via the qbs config command? > > So I have done this, and once I worked out namespace and quoting issues it works. > > The only problem is that a lot on string-munging is required to convert: > > CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security > CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 > CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security > LDFLAGS=-Wl,-z,relro > into > qbs config --settings-dir /tmp profiles.default.cpp.debugInformation true > qbs config --settings-dir /tmp profiles.default.cpp.optimization fast > qbs config --settings-dir /tmp profiles.default.cpp.commonCompilerFlags -Wdate-time > qbs config --settings-dir /tmp profiles.default.cpp.defines '[ "FORTIFY_SOURCE=2" ]' > qbs config --settings-dir /tmp profiles.default.cpp.cFlags '[ "-fstack-protector-strong", "-Wformat", "-Werror=format-security" ]' > qbs config --settings-dir /tmp profiles.default.cpp.cxxFlags '[ "-fstack-protector-strong", "-Wformat" "-Werror=format-security" ]' > qbs config --settings-dir /tmp profiles.default.cpp.linkerFlags "-z,relro" > > So I can do this for a static config of current build flags, but some > work would be involved in automating this so that it still worked when > the flags changed (they do from time to time, and can be changed > per-user, per-system etc). We wouldn't want every debian rules file to > have to have a lot of boilerplate for this conversion. The pure format conversion could probably easily automated, but the translation from raw compiler option to qbs convenience property is a bit of an issue, I suppose. Christian From hkarel at yandex.ru Thu Dec 21 18:28:14 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Thu, 21 Dec 2017 20:28:14 +0300 Subject: [Qbs] Load qt-plugins Message-ID: Hi, everyone For my project, in addition to linking qt libraries, it also requires qt-plugins. Where I can be placed the qt-plugins so that they can be seen the main qt libraries? For example. Main dir project: /opt/myproj Qt-libs: /opt/myproj/lib Where should the directory with plugins be located? -- BR, Pavel Karelin -------------- next part -------------- An HTML attachment was scrubbed... URL: From heiko.nardmann at itechnical.de Fri Dec 22 10:13:23 2017 From: heiko.nardmann at itechnical.de (Heiko Nardmann) Date: Fri, 22 Dec 2017 10:13:23 +0100 Subject: [Qbs] Load qt-plugins In-Reply-To: References: Message-ID: Maybe use a qt.conf? /Kind regards,/     Heiko Am 21.12.2017 um 18:28 schrieb Карелин Павел: > Hi, everyone > > For my project, in addition to linking qt libraries, it also requires > qt-plugins. > Where I can be placed the qt-plugins so that they can be seen the main > qt libraries? > > For example. > Main dir project: /opt/myproj > Qt-libs: /opt/myproj/lib > > Where should the directory with plugins be located? > > -- > BR, Pavel Karelin -------------- next part -------------- An HTML attachment was scrubbed... URL: From wookey at wookware.org Fri Dec 22 12:01:53 2017 From: wookey at wookware.org (Wookey) Date: Fri, 22 Dec 2017 11:01:53 +0000 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171221094036.12f6a214@ckandeler-archlinux> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> <20171221043534.v6k4sbeeadmvndrm@mail.wookware.org> <20171221094036.12f6a214@ckandeler-archlinux> Message-ID: <20171222110153.4afstyskgiaocxub@mail.wookware.org> On 2017-12-21 09:40 +0100, Christian Kandeler wrote: > On Thu, 21 Dec 2017 04:35:34 +0000 > Wookey wrote: > > > You suggested > > > qbs build --no-install modules.qbs.installRoot:debian/tmp > > > qbs install --no-build modules.qbs.installRoot:debian/tmp > > However this breaks the build, because nothing gets installed into debian/tmp. > > Works for me. Which version of qbs is this? 1.8.1 > You should pass in an absolute path, by the way, e.g.: > $ qbs build --no-install modules.qbs.installRoot:$PWD/debian/tmp OK. It still fails even with absolute paths. I have just uploaded dewalls 1.0.0+ds1-3 which has my test case in it. Change qbs install --settings-dir /tmp --no-build \ --install-root $(PWD)/debian/tmp \ profile:deb \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ qbs-build to qbs install --settings-dir /tmp --no-build \ modules.qbs.installRoot:$(PWD)/debian/tmp \ profile:deb \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ qbs-build and nothing is installed in $(PWD)/debian/tmp > Also note that from qbs 1.9 on, you don't have to repeat any of the properties on subsequent qbs invocations, as the values are stored in the build graph. That'll be nice, but still 1.8 in debian unstable. One other thing that is an issue for debian: qbs clean doesn't actually clean out all it's files, indeed it'll create one. It always leaves a $(PWD)/default/default.bg (or whatever build-dir name is in use). The debian build notices this new binary file added to the source tree and complains. A clean comand is supposed to clean out generated files, not generate more :-) Is there a way to stop this behaviour? I am using this command: qbs clean --settings-dir /tmp profile:deb qbs-build which makes a qbs-build/qbs-build.bg and also doesn't actually remove all the files in qbs-build. It removes the built binaries and the .o files but not the directories they were assembled in. I have to do an 'rm -r qbs-build' anyway. Does the qbs clean command actually do anything else significant (e.g. in the settings dir) or should I just skip it and use 'rm -r qbs-build' ? And finally, running tests. A debian build runs build-time tests after building, but before installing the files into the package location. Should I expect 'qbs run' to run a test program that needs a library, after being built, or does it also have to be installed? Qbs knows where it built the library, so it seems that it should be able to find it, I can't put my own LD_PRELOAD in because Qbs has used some magic directory ID to put it in which I don't know. How is this expected to work? currently my test-case has a product for the library and a 'dewalls-test' product for the test binary. But qbs run --settings-dir /tmp --no-build -p dewalls-test \ modules.qbs.installRoot:$(PWD)/debian/tmp \ project.libDir:lib/$(DEB_HOST_MULTIARCH) \ profile:deb qbs-build only works if the package is actually installed on the build system, otherwise the library is not found: qbs run --settings-dir /tmp --no-build -p dewalls-test \ modules.qbs.installRoot:/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/debian/tmp \ project.libDir:lib/x86_64-linux-gnu \ profile:deb qbs-build Restoring build graph from disk Installing Starting target '/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/qbs-build/dewalls-test.deb.384b8e5c/dewalls-test'. /home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/qbs-build/dewalls-test.deb.384b8e5c/dewalls-test: error while loading shared libraries: libdewalls.so.1: cannot open shared object file: No such file or directory debian/rules:36: recipe for target 'override_dh_auto_build' failed I've updated the debian Qbs wiki page, adding some info on the debian multiarch page on making it work with Qbs, and put some info on the various issues into https://bugreports.qt.io/browse/QBS-417 Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From christian.kandeler at qt.io Fri Dec 22 13:15:28 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 22 Dec 2017 13:15:28 +0100 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171222110153.4afstyskgiaocxub@mail.wookware.org> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> <20171221043534.v6k4sbeeadmvndrm@mail.wookware.org> <20171221094036.12f6a214@ckandeler-archlinux> <20171222110153.4afstyskgiaocxub@mail.wookware.org> Message-ID: <20171222131528.43d81143@ckandeler-archlinux> On Fri, 22 Dec 2017 11:01:53 +0000 Wookey wrote: > On 2017-12-21 09:40 +0100, Christian Kandeler wrote: > > On Thu, 21 Dec 2017 04:35:34 +0000 > > Wookey wrote: > > > > > You suggested > > > > qbs build --no-install modules.qbs.installRoot:debian/tmp > > > > qbs install --no-build modules.qbs.installRoot:debian/tmp > > > However this breaks the build, because nothing gets installed into debian/tmp. > > > > Works for me. Which version of qbs is this? > > 1.8.1 Hm, ok. May just be a bug in that version. > One other thing that is an issue for debian: > > qbs clean doesn't actually clean out all it's files, indeed it'll > create one. It always leaves a $(PWD)/default/default.bg (or whatever > build-dir name is in use). The debian build notices this new binary > file added to the source tree and complains. A clean comand is > supposed to clean out generated files, not generate more :-) > > Is there a way to stop this behaviour? If it really creates that file, then there was no build directory to begin with (this is an error from 1.10 on, btw). The .bg file is the build graph which contains all the meta data about the project, so it cannot be removed. Compare to "make clean", which does not remove the Makefile either. I suppose we could add a "distclean" equivalent, e.g.: $ qbs clean --wipe # simply removes the build dir > I am using this command: > qbs clean --settings-dir /tmp profile:deb qbs-build > which makes a qbs-build/qbs-build.bg ... if you haven't built the project before in that directory. Otherwise, the file has already existed. > and also doesn't actually remove all the files in qbs-build. It > removes the built binaries and the .o files but not the directories > they were assembled in. If the directories are empty, they should be removed as well. If that does not happen for you and you can reproduce the behavior with the current release, please file a bug report. > I have to do an 'rm -r qbs-build' anyway. Does the qbs clean command > actually do anything else significant (e.g. in the settings dir) or > should I just skip it and use 'rm -r qbs-build' ? For your purpose, rm is the right tool. qbs clean is more relevant to the development cycle, where you want to keep the meta data (though it should hardly ever be needed). > And finally, running tests. > > A debian build runs build-time tests after building, but before installing the > files into the package location. > > Should I expect 'qbs run' to run a test program that needs a library, > after being built, or does it also have to be installed? Qbs knows > where it built the library, so it seems that it should be able to find > it, I can't put my own LD_PRELOAD in because Qbs has used some magic > directory ID to put it in which I don't know. > > How is this expected to work? The run command does not currently consider library dependencies (but it will in qbs 1.11). > currently my test-case has a product for the library and a > 'dewalls-test' product for the test binary. But > > qbs run --settings-dir /tmp --no-build -p dewalls-test \ > modules.qbs.installRoot:$(PWD)/debian/tmp \ > project.libDir:lib/$(DEB_HOST_MULTIARCH) \ > profile:deb qbs-build > > only works if the package is actually installed on the build system, > otherwise the library is not found: Right, but setting LD_LIBRARY_PATH to /lib should do the trick there, I suppose. Also, since tests are not typically installed, I wonder why they can't simply use rpaths. Christian From hkarel at yandex.ru Fri Dec 22 14:01:24 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Fri, 22 Dec 2017 16:01:24 +0300 Subject: [Qbs] Load qt-plugins In-Reply-To: References: Message-ID: <34709dbb-6747-3a70-50e9-cb426c031980@yandex.ru> Yes qt.conf - helped. I have understood it independently, but I could not immediately write about it. But anyway thanks for the advice :) -- Pavel 22.12.2017 12:13, Heiko Nardmann пишет: > Maybe use a qt.conf? > > > /Kind regards,/ > >     Heiko > > Am 21.12.2017 um 18:28 schrieb Карелин Павел: >> Hi, everyone >> >> For my project, in addition to linking qt libraries, it also requires >> qt-plugins. >> Where I can be placed the qt-plugins so that they can be seen the >> main qt libraries? >> >> For example. >> Main dir project: /opt/myproj >> Qt-libs: /opt/myproj/lib >> >> Where should the directory with plugins be located? >> >> -- >> BR, Pavel Karelin > > > > _______________________________________________ > 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 wookey at wookware.org Sat Dec 23 03:18:08 2017 From: wookey at wookware.org (Wookey) Date: Sat, 23 Dec 2017 02:18:08 +0000 Subject: [Qbs] Qbs and debian packaging In-Reply-To: <20171222110153.4afstyskgiaocxub@mail.wookware.org> References: <20171220045444.czuxf3nnh4dt32n4@mail.wookware.org> <20171220110901.6135f7a3@ckandeler-archlinux> <20171221043534.v6k4sbeeadmvndrm@mail.wookware.org> <20171221094036.12f6a214@ckandeler-archlinux> <20171222110153.4afstyskgiaocxub@mail.wookware.org> Message-ID: <20171223021808.molj6evvrvt7mv5j@mail.wookware.org> On 2017-12-22 11:01 +0000, Wookey wrote: > On 2017-12-21 09:40 +0100, Christian Kandeler wrote: > And finally, running tests. > > currently my test-case has a product for the library and a > 'dewalls-test' product for the test binary. But > > qbs run --settings-dir /tmp --no-build -p dewalls-test \ > modules.qbs.installRoot:$(PWD)/debian/tmp \ > project.libDir:lib/$(DEB_HOST_MULTIARCH) \ > profile:deb qbs-build > > only works if the package is actually installed on the build system, > otherwise the library is not found: > > qbs run --settings-dir /tmp --no-build -p dewalls-test \ > modules.qbs.installRoot:/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/debian/tmp \ > project.libDir:lib/x86_64-linux-gnu \ > profile:deb qbs-build > Restoring build graph from disk > Installing > Starting target '/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/qbs-build/dewalls-test.deb.384b8e5c/dewalls-test'. > /home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/qbs-build/dewalls-test.deb.384b8e5c/dewalls-test: error while loading shared libraries: libdewalls.so.1: cannot open shared object file: No such file or directory > debian/rules:36: recipe for target 'override_dh_auto_build' failed It turns out that an rpath is being put in, but it is the final system rpath: /usr/lib/x86_64-linux-gnu/ which would be good if we were installing this binary as aprt of the package, but we are not - it's just a test binary to be run at build-time. So I fixed this by explicitly setting the rpath: cpp.rpaths: ["qbs-build/install-root/usr/lib/x86_64-linux-gnu/"] (because 'qbs run' is run with $PWD in the source dir and that's where rpaths have to be relative to). A better version is: cpp.rpaths: ["qbs-build/install-root/" + qbs.installPrefix + project.libDir] but that still has the build dir in it, which seems ugly, so doing it relative to the binary seems better still: cpp.rpaths: ["$ORIGIN/../install-root/" + qbs.installPrefix + project.libDir] But isn't this exactly what Qbs could be doing for me? I suspect I am doing this wrong, and there is a better way. In the debian build context where we have control of the profile and build-dir in use this does work fine, but seems clunky. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: