From christian.kandeler at qt.io Wed Nov 1 11:02:15 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 1 Nov 2017 11:02:15 +0100 Subject: [Qbs] build graph and dependency visualisation In-Reply-To: <4210d509-e3ab-0f7a-5674-e9b1a678bb7d@gmail.com> References: <4210d509-e3ab-0f7a-5674-e9b1a678bb7d@gmail.com> Message-ID: <20171101110215.5b093b09@ckandeler-archlinux> On Tue, 31 Oct 2017 12:42:33 +1300 Christian Gagneraud wrote: > Is it possible to dump the build graph (eg for graphviz), There is the dump-nodes-tree command, which gives you a textual representation. You won't have much fun looking at a graphical representation of any non-trivial project. > and the build dependencies. If not, are there any plan? No and no. Though I suppose the list-products command could be extended to cover that, if there is a use case. Christian From christian.kandeler at qt.io Wed Nov 1 11:09:03 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 1 Nov 2017 11:09:03 +0100 Subject: [Qbs] Passing unescaped flags to the linker In-Reply-To: References: Message-ID: <20171101110903.4b88d490@ckandeler-archlinux> On Tue, 31 Oct 2017 15:59:47 +0100 Benjamin TERRIER wrote: > I am experimenting with qbs and a gcc toolchain for an embedded arm > device. Is there a way > to pass unescaped flags to g++ when invoking the linker ? > > For instance I need to pass "--specs=nano.specs" to g++. If I put it > in cpp.linkerFlags it does > not work as qbs will escape it with "-Wl". I can put it in > cpp.driverFlags, but then it get passed > to every call to g++ which is useless and generates warning when using > Clang Static Analyzer: > > clang.exe: warning: argument unused during compilation: '--specs=nano.specs' Yes, that is a bit of a problem. We really need cpp.linkerDriverFlags with the semantics "flags to pass only when linking using the compiler binary". The need for that has been debated in the past, but I think the case is pretty clear now. Could you please create a task for that at bugreports.qt.io, citing your use case? Thanks, Christian From b.terrier at gmail.com Thu Nov 2 10:58:59 2017 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Thu, 2 Nov 2017 10:58:59 +0100 Subject: [Qbs] Passing unescaped flags to the linker In-Reply-To: <20171101110903.4b88d490@ckandeler-archlinux> References: <20171101110903.4b88d490@ckandeler-archlinux> Message-ID: 2017-11-01 11:09 GMT+01:00 Christian Kandeler : > > Yes, that is a bit of a problem. We really need cpp.linkerDriverFlags with > the semantics "flags to pass only when linking using the compiler binary". > The need for that has been debated in the past, but I think the case is > pretty clear now. Could you please create a task for that at > bugreports.qt.io, citing your use case? > > > Thanks, > Christian > It's done: QBS-1236 Br, Benjamin -------------- next part -------------- An HTML attachment was scrubbed... URL: From timur.kristof at gmail.com Thu Nov 2 11:19:11 2017 From: timur.kristof at gmail.com (=?UTF-8?Q?Timur_Krist=C3=B3f?=) Date: Thu, 2 Nov 2017 11:19:11 +0100 Subject: [Qbs] Passing unescaped flags to the linker In-Reply-To: References: <20171101110903.4b88d490@ckandeler-archlinux> Message-ID: @Christian: >> Yes, that is a bit of a problem. We really need cpp.linkerDriverFlags with >> the semantics "flags to pass only when linking using the compiler binary". >> The need for that has been debated in the past, but I think the case is >> pretty clear now. Could you please create a task for that at >> bugreports.qt.io, citing your use case? This exact same issue comes up twice every month on this mailing list, so I think the documentation could be improved, maybe the cpp module docs could explain better what linkerFlags and driverFlags do. Would also be nice to see a new linkerDriverFlags property which could indeed ease this problem. @Benjamin: > For instance I need to pass "--specs=nano.specs" to g++. If I put it > in cpp.linkerFlags it does > not work as qbs will escape it with "-Wl". I can put it in > cpp.driverFlags, but then it get passed > to every call to g++ which is useless Those flags may not be necessary for the compiler, but they won't hurt either. > and generates warning when using > Clang Static Analyzer How do you use the Clang Static Analyzer? I tried too, and for me it does not complain about those flags. Maybe we use it differently or use a different version? Best regards, Timur From christian.kandeler at qt.io Thu Nov 2 11:29:27 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 2 Nov 2017 11:29:27 +0100 Subject: [Qbs] Passing unescaped flags to the linker In-Reply-To: References: <20171101110903.4b88d490@ckandeler-archlinux> Message-ID: <20171102112927.26afdb68@ckandeler-archlinux> On Thu, 2 Nov 2017 11:19:11 +0100 Timur Kristóf wrote: > @Christian: > > >> Yes, that is a bit of a problem. We really need cpp.linkerDriverFlags with > >> the semantics "flags to pass only when linking using the compiler binary". > >> The need for that has been debated in the past, but I think the case is > >> pretty clear now. Could you please create a task for that at > >> bugreports.qt.io, citing your use case? > > This exact same issue comes up twice every month on this mailing list, > so I think the documentation could be improved, maybe the cpp module > docs could explain better what linkerFlags and driverFlags do. This is https://bugreports.qt.io/browse/QBS-1213 > Would also be nice to see a new linkerDriverFlags property which could > indeed ease this problem. https://codereview.qt-project.org/#/c/209971/ Christian From b.terrier at gmail.com Thu Nov 2 11:37:27 2017 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Thu, 2 Nov 2017 11:37:27 +0100 Subject: [Qbs] Passing unescaped flags to the linker In-Reply-To: References: <20171101110903.4b88d490@ckandeler-archlinux> Message-ID: 2017-11-02 11:19 GMT+01:00 Timur Kristóf : >> For instance I need to pass "--specs=nano.specs" to g++. If I put it >> in cpp.linkerFlags it does >> not work as qbs will escape it with "-Wl". I can put it in >> cpp.driverFlags, but then it get passed >> to every call to g++ which is useless > > Those flags may not be necessary for the compiler, but they won't hurt either. This particular flag doesn't hurt g++, but it creates noise by passing necessary text in the command lines. Also there is no guarantee that every flag that need to be passed to the compiler at link time will not generate a warning or an error, and that for every compiler. >> and generates warning when using >> Clang Static Analyzer > > How do you use the Clang Static Analyzer? I tried too, and for me it > does not complain about those flags. Maybe we use it differently or > use a different version? I use the latest versions (Qt Creator 4.4.1 and QBS 1.9.1) available on Windows. I just configured a Kit with my ARM toolchain, created a minimal qbs project that compile and run the static analyzer. If I managed to make the Build step works, I haven't managed to make the static analyzer work completely. My first issue is that clang ignores the system includes in the sysroot (every libc or STL include fails), so I had to add those folders with cpp.includePaths (also I haven't found a way to add those only when running the static analyzer: putting a condition on the compiler does not work as gcc is still considered to be the compiler even if it is clang that does the static analysis). My current issue is that clang fails each time it meets a bit of assembly code in a c/c++ file, likely because it does not use the ARM assembler. Br, Benjamin From timur.kristof at gmail.com Thu Nov 2 11:50:53 2017 From: timur.kristof at gmail.com (=?UTF-8?Q?Timur_Krist=C3=B3f?=) Date: Thu, 2 Nov 2017 11:50:53 +0100 Subject: [Qbs] Passing unescaped flags to the linker In-Reply-To: References: <20171101110903.4b88d490@ckandeler-archlinux> Message-ID: Hi, > I use the latest versions (Qt Creator 4.4.1 and QBS 1.9.1) available on Windows. > I just configured a Kit with my ARM toolchain, created a minimal qbs > project that compile > and run the static analyzer. What I did was to set up scan-build as a compiler wrapper in my qbs file, so arm-none-eabi-g++ ... becomes scan-build arm-none-eabi-g++ ... And it didn't complain for any of those flags. But this was months ago, and I couldn't exactly figure out how to make it work (due to qbs-unrelated issues), so maybe the latest version of the static analyzer works differently now. > If I managed to make the Build step works, I haven't managed to make > the static analyzer work completely. > My first issue is that clang ignores the system includes in the > sysroot (every libc or STL include fails), > so I had to add those folders with cpp.includePaths (also I haven't > found a way to add those only when > running the static analyzer: putting a condition on the compiler does > not work as gcc is still considered to be the compiler > even if it is clang that does the static analysis). My current issue > is that clang fails each time > it meets a bit of assembly code in a c/c++ file, likely because it > does not use the ARM assembler. After my initial experiments, I thought there must be someone who made it work, so I posted a StackOverflow question. It is still unsolved, but maybe it is of some help to you: https://stackoverflow.com/questions/44204695/how-to-use-clang-static-analyzer-with-a-cortex-m-project Now we are off-topic with regards to the qbs mailing list, but I'm very interested in your static analyzer effort, so please let me know if you find a way to get it working! Thanks, Timur From chgans at gmail.com Thu Nov 2 22:13:11 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Fri, 3 Nov 2017 10:13:11 +1300 Subject: [Qbs] build graph and dependency visualisation In-Reply-To: <20171101110215.5b093b09@ckandeler-archlinux> References: <4210d509-e3ab-0f7a-5674-e9b1a678bb7d@gmail.com> <20171101110215.5b093b09@ckandeler-archlinux> Message-ID: <2a540cae-4761-627b-fa52-e95c6c0a4e30@gmail.com> On 1/11/2017 11:02 PM, Christian Kandeler wrote: > On Tue, 31 Oct 2017 12:42:33 +1300 Christian Gagneraud > wrote: > >> Is it possible to dump the build graph (eg for graphviz), > > There is the dump-nodes-tree command, which gives you a textual > representation. You won't have much fun looking at a graphical > representation of any non-trivial project. > >> and the build dependencies. If not, are there any plan? > > No and no. Though I suppose the list-products command could be > extended to cover that, if there is a use case. I should have been more precise, I'm interested in product inter-dependencies, not build/source files dependencies, I think the graph will still be a bit messy, but there are tool to massage and visualise dot files, it's all about giving the right hints. I will have a look at dump-nodes-tree and list-products. Thanks, Chris > > > Christian _______________________________________________ Qbs mailing > list Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs > From timur.kristof at gmail.com Fri Nov 3 10:03:35 2017 From: timur.kristof at gmail.com (=?UTF-8?Q?Timur_Krist=C3=B3f?=) Date: Fri, 3 Nov 2017 10:03:35 +0100 Subject: [Qbs] Layout of qbs cpp documentation Message-ID: Hi, I've recently visited the docs at http://doc.qt.io/qbs/cpp-module.html It looks like this: https://imgur.com/a/SwIm6 Is this the intended look-and-feel of the docs? I think it is currently very hard to read with all the property descriptions squeezed in that table and hidden with a scroll bar. Even if I stretch the browser window accross two monitors it doesn't get better. Is there a way to improve it? For example, the QML docs look like this: http://doc.qt.io/qt-5/qml-qtquick-flickable.html They have a list of all properties and then a section for a longer description for each of them. I think this format is much more readable, and also gives the opportunity to provide code samples within the description. Could we change the current layout of the qbs docs to match that of the qml docs? Best regards, Timur From oswald.buddenhagen at qt.io Fri Nov 3 10:10:28 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 3 Nov 2017 10:10:28 +0100 Subject: [Qbs] Layout of qbs cpp documentation In-Reply-To: References: Message-ID: <20171103091028.GA20250@ugly> On Fri, Nov 03, 2017 at 10:03:35AM +0100, Timur Kristóf wrote: > I've recently visited the docs at http://doc.qt.io/qbs/cpp-module.html > It looks like this: https://imgur.com/a/SwIm6 > > Is this the intended look-and-feel of the docs? > https://bugreports.qt.io/browse/QBS-1195 > Could we change the current layout of the qbs docs to match that of > the qml docs? > i suppose that would be an option. From chgans at gmail.com Fri Nov 3 23:42:00 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Sat, 4 Nov 2017 11:42:00 +1300 Subject: [Qbs] Passing unescaped flags to the linker In-Reply-To: References: <20171101110903.4b88d490@ckandeler-archlinux> Message-ID: On 2 November 2017 at 23:50, Timur Kristóf wrote: > Hi, > >> I use the latest versions (Qt Creator 4.4.1 and QBS 1.9.1) available on Windows. >> I just configured a Kit with my ARM toolchain, created a minimal qbs >> project that compile >> and run the static analyzer. > > What I did was to set up scan-build as a compiler wrapper in my qbs file, so > arm-none-eabi-g++ ... > becomes > scan-build arm-none-eabi-g++ ... > And it didn't complain for any of those flags. But this was months > ago, and I couldn't exactly figure out how to make it work (due to > qbs-unrelated issues), so maybe the latest version of the static > analyzer works differently now. > >> If I managed to make the Build step works, I haven't managed to make >> the static analyzer work completely. >> My first issue is that clang ignores the system includes in the >> sysroot (every libc or STL include fails), >> so I had to add those folders with cpp.includePaths (also I haven't >> found a way to add those only when >> running the static analyzer: putting a condition on the compiler does >> not work as gcc is still considered to be the compiler >> even if it is clang that does the static analysis). My current issue >> is that clang fails each time >> it meets a bit of assembly code in a c/c++ file, likely because it >> does not use the ARM assembler. > > After my initial experiments, I thought there must be someone who made > it work, so I posted a StackOverflow question. > It is still unsolved, but maybe it is of some help to you: > https://stackoverflow.com/questions/44204695/how-to-use-clang-static-analyzer-with-a-cortex-m-project > > Now we are off-topic with regards to the qbs mailing list, but I'm > very interested in your static analyzer effort, so please let me know > if you find a way to get it working! To get rid of errors/warnings in external headers, you have to use -isystem instead of -I, clang wont complain about code in system headers. In our project any "foreign" include path is added with -isystem, this includes Qt too. There's the -isysroot as well as explained on QtC mailing list. Have you tried to export the clang compilation database with Qbs and then use it with your clang-based tool? Chris From xbenlau at gmail.com Mon Nov 6 03:24:07 2017 From: xbenlau at gmail.com (Ben Lau) Date: Mon, 6 Nov 2017 10:24:07 +0800 Subject: [Qbs] Why is there Rule:alwaysRun but not Probe:alwaysRun? In-Reply-To: References: Message-ID: Something like rerunOnFileChange is a nice idea. I would suggest it should be able to monitor folder too. By the way, I could provide another use-case. For example, if a user downloads a library from the Internet in a way like qpm/npm. (Remarks. qpm does not support QBS now. I am talking about a way to implement it by using QBS itself) In using this method, the library dependency is not managed by the user themselves. User expects the newly downloaded library should be added to their build system after running the command. An auto re-run Probe item should help to implement such kind of system. On 17 October 2017 at 21:45, NIkolai Marchenko wrote: > I could just as well ask you to provide a use case for why is it necessary > to update the Rule artifacts that don't need updating (according to QBS). > Yet alwaysRun still exists. > > As for Probes: getting the git tag and commit is certainly possible by > attaching to a HEAD file in the repo, > but this is completely counterintuitive and getting a tag and commit very > certainly is not an > "expensive operation that takes time". Why not simply let us set alwaysRun > and take responsibility for this running each time? > > Or, if you think it more sensible, provide an option for the probe > rerunOnFileChange: [list of files] > which is what people are doing at the moment anyway so you might as well > make it officialy supported function > > On Tue, Oct 17, 2017 at 4:33 PM, Joerg Bornemann > wrote: > >> On 10/17/2017 02:55 PM, NIkolai Marchenko wrote: >> >> Both run arbitary scripts to do their work. QBS cannot assume that one >>> script is better or more expensive than the other since both are arbitary >>> and external to build system. So why defend the policy of not allowing >>> alwaysSrun for Probes ? This makes no sense to me >>> >> >> Could you sketch a use case for probes that always run, please? >> >> >> Cheers, >> >> Joerg >> _______________________________________________ >> 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 Tue Nov 7 23:31:04 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 8 Nov 2017 11:31:04 +1300 Subject: [Qbs] Layout of qbs cpp documentation In-Reply-To: <20171103091028.GA20250@ugly> References: <20171103091028.GA20250@ugly> Message-ID: On 3/11/2017 10:10 PM, Oswald Buddenhagen wrote: > On Fri, Nov 03, 2017 at 10:03:35AM +0100, Timur Kristóf wrote: >> I've recently visited the docs at >> http://doc.qt.io/qbs/cpp-module.html It looks like this: >> https://imgur.com/a/SwIm6 >> >> Is this the intended look-and-feel of the docs? >> > https://bugreports.qt.io/browse/QBS-1195 > >> Could we change the current layout of the qbs docs to match that >> of the qml docs? >> > i suppose that would be an option. Another option would be to fix the HTML/CSS used for tables. Any table on doc.qt.io suffer from this (very) annoying bug. My 2 cents, Chris From Jake.Petroules at qt.io Tue Nov 7 23:34:45 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 7 Nov 2017 22:34:45 +0000 Subject: [Qbs] Layout of qbs cpp documentation In-Reply-To: References: <20171103091028.GA20250@ugly>, Message-ID: The property documentation needs to be restructured to not use a table, period. The only reason it is a table is because we didn't have a sufficient mechanism for doing a QML property style documentation and I made the stupid decision to use tables in the meantime (at the time the descriptions were meant to be short summaries only but that isn't sufficient for real world property documentation). -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io ________________________________ From: Qbs on behalf of Christian Gagneraud Sent: Tuesday, November 7, 2017 2:31:04 PM To: qbs at qt-project.org Subject: Re: [Qbs] Layout of qbs cpp documentation On 3/11/2017 10:10 PM, Oswald Buddenhagen wrote: > On Fri, Nov 03, 2017 at 10:03:35AM +0100, Timur Kristóf wrote: >> I've recently visited the docs at >> http://doc.qt.io/qbs/cpp-module.html It looks like this: >> https://imgur.com/a/SwIm6 >> >> Is this the intended look-and-feel of the docs? >> > https://bugreports.qt.io/browse/QBS-1195 > >> Could we change the current layout of the qbs docs to match that >> of the qml docs? >> > i suppose that would be an option. Another option would be to fix the HTML/CSS used for tables. Any table on doc.qt.io suffer from this (very) annoying bug. My 2 cents, Chris _______________________________________________ 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 resurrection at centrum.cz Wed Nov 8 09:28:30 2017 From: resurrection at centrum.cz (resurrection at centrum.cz) Date: Wed, 08 Nov 2017 09:28:30 +0100 Subject: [Qbs] =?utf-8?q?Build_QTests_from_single_Product?= Message-ID: <20171108092830.FB284ED5@centrum.cz> In other testing frameworks like Google Test the test executable typically contains all test cases for the given module under test so there typically are as many products for tests as there are production modules. With QTest this is unsupported (although doable) and for good reasons too (mainly separation of test runs). As a result this requires each test case to be a separate executable and thus a separate Product under Qbs. While some code duplicity could be avoided by extracting most of the qbs code into custom item and instantiating that, the issue of the project list and the running executable(s) lists will be absolutely cluttered with every class being a separate Product (think Qt itself or even Qt Creator projects). Now the multiplexing sounds just like the right thing for this as one could pass the `files` property to `multiplexByQbsProperties` and it should work as expected building an executable for each file. Unfortunately that is not currently possible as `multipl exByQbsP roperties` is limited only to one of `["architectures", "buildVariants", "profiles"]`.   Incidentally this hints towards what I would absolutely love to see in Qbs and that is kind of there but not quite - dynamically defined Products. The multiplexing is just that - you defined a product and told Qbs to build it n times with these different settings. Custom items are almost that with the big limitation that you have to actually instantiate them manually rather than based on some property(ies). The QTest issue is a variation on this: "build this Product for every file in this list". Currently I need to go and instantiate the custom item manually for each test case. And it could be pushed a bit further by being able to say build this Product for every directory in this list with files being extracted dynamically etc. That would essentially remove the raison d'être for the qbs-autoproject that is doing exactly that - moving from manually defining each product to defining rules for a product type/category letting the build system to extract the project/products and build t hem.   So my ultimate question I guess is what are the plans regarding multiplexing? Will it be expanded into more general Qbs feature or kept limited to the special (Apple mainly) use case(s)? And what about the QTests?   Best wishes, Michael From Jake.Petroules at qt.io Wed Nov 8 17:15:01 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 8 Nov 2017 16:15:01 +0000 Subject: [Qbs] Build QTests from single Product In-Reply-To: <20171108092830.FB284ED5@centrum.cz> References: <20171108092830.FB284ED5@centrum.cz> Message-ID: <760472D2-72DA-4FBE-BF88-9E94F1315A26@qt.io> The simple answer is that multiplexing is limited to those 3 properties right now for technical reasons. In terms of the design concept, I certainly would have liked to allow it to work over ANY property, but we ran into limitations with the implementation. At least right now, it's technically possible to add an unlimited number of multiplexing axes simply by modifying common.qbs (i.e. it requires no changes to the engine), but only properties of the qbs module can be multiplexed, not others. So something like Product.files/Group.files is out of the question at least for now. If you can argue for multiplexing over a particular qbs module property, feel free to propose a patch and we may consider adding it. > On Nov 8, 2017, at 12:28 AM, resurrection at centrum.cz wrote: > > In other testing frameworks like Google Test the test executable typically contains all test cases for the given module under test so there typically are as many products for tests as there are production modules. With QTest this is unsupported (although doable) and for good reasons too (mainly separation of test runs). As a result this requires each test case to be a separate executable and thus a separate Product under Qbs. While some code duplicity could be avoided by extracting most of the qbs code into custom item and instantiating that, the issue of the project list and the running executable(s) lists will be absolutely cluttered with every class being a separate Product (think Qt itself or even Qt Creator projects). Now the multiplexing sounds just like the right thing for this as one could pass the `files` property to `multiplexByQbsProperties` and it should work as expected building an executable for each file. Unfortunately that is not currently possible as `multipl > exByQbsP > roperties` is limited only to one of `["architectures", "buildVariants", "profiles"]`. > > Incidentally this hints towards what I would absolutely love to see in Qbs and that is kind of there but not quite - dynamically defined Products. The multiplexing is just that - you defined a product and told Qbs to build it n times with these different settings. Custom items are almost that with the big limitation that you have to actually instantiate them manually rather than based on some property(ies). The QTest issue is a variation on this: "build this Product for every file in this list". Currently I need to go and instantiate the custom item manually for each test case. And it could be pushed a bit further by being able to say build this Product for every directory in this list with files being extracted dynamically etc. That would essentially remove the raison d'être for the qbs-autoproject that is doing exactly that - moving from manually defining each product to defining rules for a product type/category letting the build system to extract the project/products and > build t > hem. > > So my ultimate question I guess is what are the plans regarding multiplexing? Will it be expanded into more general Qbs feature or kept limited to the special (Apple mainly) use case(s)? And what about the QTests? > > Best wishes, > Michael > _______________________________________________ > Qbs mailing list > Qbs 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 resurrection at centrum.cz Wed Nov 8 18:12:35 2017 From: resurrection at centrum.cz (resurrection at centrum.cz) Date: Wed, 08 Nov 2017 18:12:35 +0100 Subject: [Qbs] =?utf-8?q?Build_QTests_from_single_Product?= In-Reply-To: 000000001a6200050b5803cd98ac References: <20171108092830.FB284ED5@centrum.cz> 000000001a6200050b5803cd98ac Message-ID: <20171108181235.5BDDFAA6@centrum.cz> I tried what you suggested and it seems to work without problems:   In common.qbs I created two new properties:   ``` property stringList files: []` property string file ```   And modified the internal property:   ``` readonly property var multiplexMap: ({     files: "file",     profiles: "profile",     architectures: "architecture",     buildVariants: "buildVariant" }) ```   Now in a product: ``` CppApplication { qbs.files: ["main.cpp", "main2.cpp"] files: qbs.file name: FileInfo.baseName(qbs.file)}``` And in another in the same project:``` CppApplication { qbs.files: ["main3.cpp", "main4.cpp"] files: qbs.file name: FileInfo.baseName(qbs.file)}``` Not only this works and builds correctly all 4 executables but there also seems to be no errors or clashes even when used in multiple products. And it is even correctly picked up by Qt Creator! As I understand it as common.qbs defines a module its instance is part of every single project so they do not affect each other (that is why this works). And yes, adding more multiplexing properties seems super easy so I really wonder what is it that is stopping you from opening it up for any property but I will take your word for it. The only problem I have with this workaround is that it requires editing common.qbs that is more than non-standard use but I can live with it for now as it gets the job done nicely. Thanks! ______________________________________________________________ > Od: Jake Petroules > Komu: "resurrection at centrum.cz" > Datum: 08.11.2017 17:15 > Předmět: Re: [Qbs] Build QTests from single Product > > CC: The simple answer is that multiplexing is limited to those 3 properties right now for technical reasons. In terms of the design concept, I certainly would have liked to allow it to work over ANY property, but we ran into limitations with the implementation. At least right now, it's technically possible to add an unlimited number of multiplexing axes simply by modifying common.qbs (i.e. it requires no changes to the engine), but only properties of the qbs module can be multiplexed, not others. So something like Product.files/Group.files is out of the question at least for now. If you can argue for multiplexing over a particular qbs module property, feel free to propose a patch and we may consider adding it. > On Nov 8, 2017, at 12:28 AM, resurrection at centrum.cz wrote: > > In other testing frameworks like Google Test the test executable typically contains all test cases for the given module under test so there typically are as many products for tests as there are production modules. With QTest this is unsupported (although doable) and for good reasons too (mainly separation of test runs). As a result this requires each test case to be a separate executable and thus a separate Product under Qbs. While some code duplicity could be avoided by extracting most of the qbs code into custom item and instantiating that, the issue of the project list and the running executable(s) lists will be absolutely cluttered with every class being a separate Product (think Qt itself or even Qt Creator projects). Now the multiplexing sounds just like the right thing for this as one could pass the `files` property to `multiplexByQbsProperties` and it should work as expected building an executable for each file. Unfortunately that is not currently possible as `mult ipl > exByQbsP > roperties` is limited only to one of `["architectures", "buildVariants", "profiles"]`. >   > Incidentally this hints towards what I would absolutely love to see in Qbs and that is kind of there but not quite - dynamically defined Products. The multiplexing is just that - you defined a product and told Qbs to build it n times with these different settings. Custom items are almost that with the big limitation that you have to actually instantiate them manually rather than based on some property(ies). The QTest issue is a variation on this: "build this Product for every file in this list". Currently I need to go and instantiate the custom item manually for each test case. And it could be pushed a bit further by being able to say build this Product for every directory in this list with files being extracted dynamically etc. That would essentially remove the raison d'être for the qbs-autoproject that is doing exactly that - moving from manually defining each product to defining rules for a product type/category letting the build system to extract the project/products and >  build t > hem. >   > So my ultimate question I guess is what are the plans regarding multiplexing? Will it be expanded into more general Qbs feature or kept limited to the special (Apple mainly) use case(s)? And what about the QTests? >   > Best wishes, > Michael > _______________________________________________ > Qbs mailing list > Qbs 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From resurrection at centrum.cz Wed Nov 8 18:22:54 2017 From: resurrection at centrum.cz (resurrection at centrum.cz) Date: Wed, 08 Nov 2017 18:22:54 +0100 Subject: [Qbs] =?utf-8?q?Build_QTests_from_single_Product?= In-Reply-To: 000000001a6200050b5803cd98ac References: <20171108092830.FB284ED5@centrum.cz> 000000001a6200050b5803cd98ac Message-ID: <20171108182254.920AC572@centrum.cz> And in fact I do have a suggestion, what about new property in the common.qbs:   property var userValues: [] property var userValue readonly property var multiplexMap: ({     userValues: "userValue",     profiles: "profile",   With this one could multiplex over pretty much anything as in any Product the userValues could be populated with objects of arbitrary structure and then qbs.userValue would contain that object if multiplexByQbsProperties: ["userValues"] was set.   Not sure how invasive or potentially problematic this change would be but I would happilly submit a patch if you think it worthwhile.   ______________________________________________________________ > Od: Jake Petroules > Komu: "resurrection at centrum.cz" > Datum: 08.11.2017 17:15 > Předmět: Re: [Qbs] Build QTests from single Product > > CC: The simple answer is that multiplexing is limited to those 3 properties right now for technical reasons. In terms of the design concept, I certainly would have liked to allow it to work over ANY property, but we ran into limitations with the implementation. At least right now, it's technically possible to add an unlimited number of multiplexing axes simply by modifying common.qbs (i.e. it requires no changes to the engine), but only properties of the qbs module can be multiplexed, not others. So something like Product.files/Group.files is out of the question at least for now. If you can argue for multiplexing over a particular qbs module property, feel free to propose a patch and we may consider adding it. > On Nov 8, 2017, at 12:28 AM, resurrection at centrum.cz wrote: > > In other testing frameworks like Google Test the test executable typically contains all test cases for the given module under test so there typically are as many products for tests as there are production modules. With QTest this is unsupported (although doable) and for good reasons too (mainly separation of test runs). As a result this requires each test case to be a separate executable and thus a separate Product under Qbs. While some code duplicity could be avoided by extracting most of the qbs code into custom item and instantiating that, the issue of the project list and the running executable(s) lists will be absolutely cluttered with every class being a separate Product (think Qt itself or even Qt Creator projects). Now the multiplexing sounds just like the right thing for this as one could pass the `files` property to `multiplexByQbsProperties` and it should work as expected building an executable for each file. Unfortunately that is not currently possible as `mult ipl > exByQbsP > roperties` is limited only to one of `["architectures", "buildVariants", "profiles"]`. >   > Incidentally this hints towards what I would absolutely love to see in Qbs and that is kind of there but not quite - dynamically defined Products. The multiplexing is just that - you defined a product and told Qbs to build it n times with these different settings. Custom items are almost that with the big limitation that you have to actually instantiate them manually rather than based on some property(ies). The QTest issue is a variation on this: "build this Product for every file in this list". Currently I need to go and instantiate the custom item manually for each test case. And it could be pushed a bit further by being able to say build this Product for every directory in this list with files being extracted dynamically etc. That would essentially remove the raison d'être for the qbs-autoproject that is doing exactly that - moving from manually defining each product to defining rules for a product type/category letting the build system to extract the project/products and >  build t > hem. >   > So my ultimate question I guess is what are the plans regarding multiplexing? Will it be expanded into more general Qbs feature or kept limited to the special (Apple mainly) use case(s)? And what about the QTests? >   > Best wishes, > Michael > _______________________________________________ > Qbs mailing list > Qbs 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Thu Nov 9 03:37:07 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Thu, 9 Nov 2017 02:37:07 +0000 Subject: [Qbs] Build QTests from single Product In-Reply-To: <20171108181235.5BDDFAA6@centrum.cz> References: <20171108092830.FB284ED5@centrum.cz> <20171108181235.5BDDFAA6@centrum.cz> Message-ID: > On Nov 8, 2017, at 9:12 AM, resurrection at centrum.cz wrote: > > I tried what you suggested and it seems to work without problems: > > In common.qbs I created two new properties: > > ``` > property stringList files: []` > property string file > ``` > > And modified the internal property: > > ``` > readonly property var multiplexMap: ({ > files: "file", > profiles: "profile", > architectures: "architecture", > buildVariants: "buildVariant" > }) > ``` > > Now in a product: > ``` > CppApplication { > qbs.files: ["main.cpp", "main2.cpp"] > files: qbs.file > name: FileInfo.baseName(qbs.file) > > } > ``` > > And in another in the same project: > ``` > > CppApplication { > qbs.files: ["main3.cpp", "main4.cpp"] > files: qbs.file > name: FileInfo.baseName(qbs.file) > > } > ``` > > Not only this works and builds correctly all 4 executables but there also seems to be no errors or clashes even when used in multiple products. And it is even correctly picked up by Qt Creator! > > As I understand it as common.qbs defines a module its instance is part of every single project so they do not affect each other (that is why this works). And yes, adding more multiplexing properties seems super easy so I really wonder what is it that is stopping you from opening it up for any property but I will take your word for it. Because the qbs module is special. Every module/product has an implicit dependency on it, and in the implementation it's loaded much earlier than other modules which leads to its properties having "special privileges". Other than that, multiplexing is possible for ANY property in the qbs module (and the case you described is supposed to work without any issue); as I said the engine has absolutely no inherent knowledge of which properties are multiplexed, just the mechanism by which it is done. > > The only problem I have with this workaround is that it requires editing common.qbs that is more than non-standard use but I can live with it for now as it gets the job done nicely. Right, that's the limitation. Regarding your proposal in the next post, I'd rather make the mechanism itself generic enough to do that across arbitrary modules, rather than strapping on a new property solely for this purpose. > > Thanks! > > ______________________________________________________________ > > Od: Jake Petroules > > Komu: "resurrection at centrum.cz" > > Datum: 08.11.2017 17:15 > > Předmět: Re: [Qbs] Build QTests from single Product > > > > CC: > The simple answer is that multiplexing is limited to those 3 properties right now for technical reasons. In terms of the design concept, I certainly would have liked to allow it to work over ANY property, but we ran into limitations with the implementation. > > At least right now, it's technically possible to add an unlimited number of multiplexing axes simply by modifying common.qbs (i.e. it requires no changes to the engine), but only properties of the qbs module can be multiplexed, not others. So something like Product.files/Group.files is out of the question at least for now. > > If you can argue for multiplexing over a particular qbs module property, feel free to propose a patch and we may consider adding it. > > > On Nov 8, 2017, at 12:28 AM, resurrection at centrum.cz wrote: > > > > In other testing frameworks like Google Test the test executable typically contains all test cases for the given module under test so there typically are as many products for tests as there are production modules. With QTest this is unsupported (although doable) and for good reasons too (mainly separation of test runs). As a result this requires each test case to be a separate executable and thus a separate Product under Qbs. While some code duplicity could be avoided by extracting most of the qbs code into custom item and instantiating that, the issue of the project list and the running executable(s) lists will be absolutely cluttered with every class being a separate Product (think Qt itself or even Qt Creator projects). Now the multiplexing sounds just like the right thing for this as one could pass the `files` property to `multiplexByQbsProperties` and it should work as expected building an executable for each file. Unfortunately that is not currently possible as `m ultipl > exByQbsP > > roperties` is limited only to one of `["architectures", "buildVariants", "profiles"]`. > > > > Incidentally this hints towards what I would absolutely love to see in Qbs and that is kind of there but not quite - dynamically defined Products. The multiplexing is just that - you defined a product and told Qbs to build it n times with these different settings. Custom items are almost that with the big limitation that you have to actually instantiate them manually rather than based on some property(ies). The QTest issue is a variation on this: "build this Product for every file in this list". Currently I need to go and instantiate the custom item manually for each test case. And it could be pushed a bit further by being able to say build this Product for every directory in this list with files being extracted dynamically etc. That would essentially remove the raison d'être for the qbs-autoproject that is doing exactly that - moving from manually defining each product to defining rules for a product type/category letting the build system to extract the project/p roducts and > > build t > > hem. > > > > So my ultimate question I guess is what are the plans regarding multiplexing? Will it be expanded into more general Qbs feature or kept limited to the special (Apple mainly) use case(s)? And what about the QTests? > > > > Best wishes, > > Michael > > _______________________________________________ > > Qbs mailing list > > Qbs 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 > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From izowiuz at gmail.com Mon Nov 13 18:46:55 2017 From: izowiuz at gmail.com (Jakub Narolewski) Date: Mon, 13 Nov 2017 18:46:55 +0100 Subject: [Qbs] Qbs, generators and automating tedious tasks Message-ID: <5a09da8c.ce472e0a.84d14.3468@mx.google.com> Hello, Let me start by saying that I am not, by any means, a long time user of Qbs and maybe there is something painfully obvious that I missed which can be used to resolve my situation. Some time ago I started researching ways in which Qbs could help me integrate awesome tools from clang land into my dev workflow. Many of them [clang-tidy, KDAB’s clazy, even cppcheck] can leverage compile commands json file to do all sorts of static analysis. To quote the documentation: “To generate a project for another build system, such as Microsoft Visual Studio, use the qbs-generate sub-command and specify a generator using the -g option. # For Visual Studio qbs generate -g visualstudio2015” Obviously, when I use QtCreator to manage my Qbs projects, inputting this command into powershell/cmd leads to errors related to not yet configured Qbs profile and Qt framework instance. I could probably add them by hand and be done with it BUT: 1. I often change Qt versions 2. I often change compilers and their versions 3. I often change my workstations 4. I am an extremely lazy person I already tried adding custom build step in QtCreator but this is suboptimal. In ideal world I would right click on a Qbs project in QtCreator treeview and select “Generate project files for- > clangdb, vsstudioXXXX, turboC++” or maybe add some custom module in *.qbs file to generate it during build time. Is there any sane way to deal with this? Jakub Narolewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at qt.io Tue Nov 14 10:38:11 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 14 Nov 2017 10:38:11 +0100 Subject: [Qbs] Qbs, generators and automating tedious tasks In-Reply-To: <5a09da8c.ce472e0a.84d14.3468@mx.google.com> References: <5a09da8c.ce472e0a.84d14.3468@mx.google.com> Message-ID: <20171114103811.55057ce4@ckandeler-archlinux> On Mon, 13 Nov 2017 18:46:55 +0100 Jakub Narolewski wrote: > Let me start by saying that I am not, by any means, a long time user of Qbs and maybe there is something painfully obvious that I missed which can be used to resolve my situation. > > Some time ago I started researching ways in which Qbs could help me integrate awesome tools from clang land into my dev workflow. > Many of them [clang-tidy, KDAB’s clazy, even cppcheck] can leverage compile commands json file to do all sorts of static analysis. > > To quote the documentation: > “To generate a project for another build system, such as Microsoft Visual Studio, use the qbs-generate sub-command and specify a generator using the -g option. > # For Visual Studio > qbs generate -g visualstudio2015” > > Obviously, when I use QtCreator to manage my Qbs projects, inputting this command into powershell/cmd leads to errors related to not yet configured Qbs profile and Qt framework instance. I could probably add them by hand and be done with it BUT: > > 1. I often change Qt versions > 2. I often change compilers and their versions > 3. I often change my workstations > 4. I am an extremely lazy person > > I already tried adding custom build step in QtCreator but this is suboptimal. In ideal world I would right click on a Qbs project in QtCreator treeview and select “Generate project files for- > clangdb, vsstudioXXXX, turboC++” or maybe add some custom module in *.qbs file to generate it during build time. > > Is there any sane way to deal with this? Generators are not exposed in the QtCreator interface at the moment, and I don't think anyone has yet spent time thinking about what that should look like and what the possible use cases and user workflows would be. You could create a task for this at bugreports.qt.io, and we can have that discussion there. Christian From izowiuz at gmail.com Tue Nov 14 20:00:56 2017 From: izowiuz at gmail.com (Jakub Narolewski) Date: Tue, 14 Nov 2017 20:00:56 +0100 Subject: [Qbs] Qbs, generators and automating tedious tasks Message-ID: <5a0b3d67.07162e0a.51c52.6d50@mx.google.com> Thank you for your reply. I have filed a suggestion under: https://bugreports.qt.io/browse/QTCREATORBUG-19298 -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Mon Nov 20 13:13:45 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 20 Nov 2017 15:13:45 +0300 Subject: [Qbs] Use DBus module with xml2CppHeaderFlags property Message-ID: Hi all, I need to port the following qmake's features to qbs: phonebook_access_iface.files = $$PWD/org.bluez.obex.PhonebookAccess1.xml phonebook_access_iface.header_flags = -i dbusphonebooktypes_p.h DBUS_INTERFACES += phonebook_access_iface for this purpose, seems, I need to use the xml2CppHeaderFlags property: https://github.com/qbs/qbs/blob/master/src/lib/qtprofilesetup/templates/dbus.qbs I don't know, where I need to declare this property: Product { ... Depends { name: "Qt"; submodules: [ "dbus" ] } ... Group { name: "My DBus data types" files: [ "dbusphonebooktypes_p.h", ] } ... Group { name: "Dbus interfaces" files: [ "...", "org.bluez.obex.PhonebookAccess1.xml", "..." ] fileTags: ["qt.dbus.interface"] } // THIS DOESN'T WORK. HOW TO USE IT? dbus.xml2CppHeaderFlags: [ "-i", "dbusphonebooktypes_p.h" ] } BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Mon Nov 20 13:29:23 2017 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 20 Nov 2017 15:29:23 +0300 Subject: [Qbs] Use DBus module with xml2CppHeaderFlags property In-Reply-To: References: Message-ID: Ahh, sorry, it works as: Qt.dbus.xml2CppHeaderFlags: [ "-i", product.sourceDirectory + "/dbusphonebooktypes_p.h" ] BR, Denis 2017-11-20 15:13 GMT+03:00 Denis Shienkov : > Hi all, > > I need to port the following qmake's features to qbs: > > phonebook_access_iface.files = $$PWD/org.bluez.obex. > PhonebookAccess1.xml > phonebook_access_iface.header_flags = -i dbusphonebooktypes_p.h > > DBUS_INTERFACES += phonebook_access_iface > > for this purpose, seems, I need to use the xml2CppHeaderFlags property: > https://github.com/qbs/qbs/blob/master/src/lib/ > qtprofilesetup/templates/dbus.qbs > > I don't know, where I need to declare this property: > > Product { > ... > Depends { name: "Qt"; submodules: [ "dbus" ] } > ... > Group { > name: "My DBus data types" > files: [ > "dbusphonebooktypes_p.h", > ] > } > ... > Group { > name: "Dbus interfaces" > files: [ > "...", > "org.bluez.obex.PhonebookAccess1.xml", > "..." > ] > > fileTags: ["qt.dbus.interface"] > } > > // THIS DOESN'T WORK. HOW TO USE IT? > dbus.xml2CppHeaderFlags: [ "-i", "dbusphonebooktypes_p.h" ] > } > > BR, > Denis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Tue Nov 21 06:01:32 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 21 Nov 2017 18:01:32 +1300 Subject: [Qbs] Tighter clang tooling integration Message-ID: <99b79f62-ff40-7ae5-6fb7-f1991cba9bf3@gmail.com> Hi, Qbs can generate a clang compilation database. Some (most) clang-based tools are not multi-cpu aware. For example a typical use of clang-check is cd repo.git qbs generate -g clangdb profile:someprofile # or cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON find path/to/some/code -name '*.cpp' | xargs clang-check -analyze -p=someprofile There are a few annoying things with this: - First you need to give clang-check which file you want to check - clang-check will process all the files one after another, even if you have multi CPU - find path/to/some/code -name '*.cpp' might retun files that should not be compiled. Wouldn't it be nice if we could ask qbs to run a clang-based tools on all the source files and with proper load distribution? Is this something that looks doable? Is it even wanted? Chris From christian.kandeler at qt.io Tue Nov 21 10:46:06 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Tue, 21 Nov 2017 10:46:06 +0100 Subject: [Qbs] Tighter clang tooling integration In-Reply-To: <99b79f62-ff40-7ae5-6fb7-f1991cba9bf3@gmail.com> References: <99b79f62-ff40-7ae5-6fb7-f1991cba9bf3@gmail.com> Message-ID: <20171121104606.4f659984@ckandeler-archlinux> On Tue, 21 Nov 2017 18:01:32 +1300 Christian Gagneraud wrote: > Qbs can generate a clang compilation database. > Some (most) clang-based tools are not multi-cpu aware. > > For example a typical use of clang-check is > cd repo.git > qbs generate -g clangdb profile:someprofile # or cmake > -DCMAKE_EXPORT_COMPILE_COMMANDS=ON > find path/to/some/code -name '*.cpp' | xargs clang-check -analyze > -p=someprofile > > There are a few annoying things with this: > - First you need to give clang-check which file you want to check > - clang-check will process all the files one after another, even if you > have multi CPU This one you can probably work around, e.g. using GNU parallel. > - find path/to/some/code -name '*.cpp' might retun files that should not > be compiled. > > Wouldn't it be nice if we could ask qbs to run a clang-based tools on > all the source files and with proper load distribution? > > Is this something that looks doable? Is it even wanted? This has come up before. It looked deceptively tempting at first to just set the compiler to the clang tool and then "build" as normal, but upon closer inspection, there were some issues. The most obvious one would be that you'd have to somehow stop after the "compile" step, but there were others as well (I forgot the details). If you play around a bit in that area (perhaps with a dedicated module?), you'll probably get more insight into where the problems lie. Christian From hkarel at yandex.ru Tue Nov 21 12:10:05 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Tue, 21 Nov 2017 14:10:05 +0300 Subject: [Qbs] Licensing of my own QBS modules Message-ID: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> Hi, guys! I wrote several modules that slightly extend the functionality of QBS. I want to place them on GitHub, for using their in both open source and commercial projects. Under what license should I place my modules? Can I use a MIT license? -- BR, Pavel Karelin -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Tue Nov 21 18:03:58 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 21 Nov 2017 17:03:58 +0000 Subject: [Qbs] Licensing of my own QBS modules In-Reply-To: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> References: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> Message-ID: Hi Pavel, As the author and copyright holder, you're free to use whatever license you want. MIT is certainly a good choice. However, depending on the kind of functionality your modules provide, you may even like to upstream them to the Qbs project for inclusion in the official release. Perhaps you could upload the modules and we can take a look and see if it's a fit? Cheers. > On Nov 21, 2017, at 3:10 AM, Карелин Павел wrote: > > Hi, guys! > > I wrote several modules that slightly extend the functionality of QBS. I want to place them on GitHub, for using their in both open source and commercial projects. Under what license should I place my modules? > Can I use a MIT license? > > -- > BR, Pavel Karelin > > > _______________________________________________ > 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 hkarel at yandex.ru Tue Nov 21 19:26:17 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Tue, 21 Nov 2017 21:26:17 +0300 Subject: [Qbs] Licensing of my own QBS modules In-Reply-To: References: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> Message-ID: <7e79e972-1463-cbbd-53cb-b611a1cb0080@yandex.ru> 21.11.2017 20:03, Jake Petroules пишет: > Hi Pavel, > > As the author and copyright holder, you're free to use whatever license you want. MIT is certainly a good choice. Ok, this is great! > > However, depending on the kind of functionality your modules provide, you may even like to upstream them to the Qbs project for inclusion in the official release. Perhaps you could upload the modules and we can take a look and see if it's a fit? Xm, I do not think that you will find in my modules that it is really valuable :)  These are just small utilities. I did not intend to publish them, but so were the circumstances. The modules are attached. -- Pavel. P.S. I work in the Russian-language segment, so all comments are in Russian. If an incredible thing happens, and you like something, then you are ready to make explanations in English. > > Cheers. > >> On Nov 21, 2017, at 3:10 AM, Карелин Павел wrote: >> >> Hi, guys! >> >> I wrote several modules that slightly extend the functionality of QBS. I want to place them on GitHub, for using their in both open source and commercial projects. Under what license should I place my modules? >> Can I use a MIT license? >> >> -- >> BR, Pavel Karelin >> >> >> _______________________________________________ >> Qbs mailing list >> Qbs at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/qbs -------------- next part -------------- A non-text attachment was scrubbed... Name: QbsExt.tar.gz Type: application/gzip Size: 46648 bytes Desc: not available URL: From hkarel at yandex.ru Tue Nov 21 19:31:09 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Tue, 21 Nov 2017 21:31:09 +0300 Subject: [Qbs] Licensing of my own QBS modules In-Reply-To: <7e79e972-1463-cbbd-53cb-b611a1cb0080@yandex.ru> References: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> <7e79e972-1463-cbbd-53cb-b611a1cb0080@yandex.ru> Message-ID: 21.11.2017 21:26, Карелин Павел пишет: > > > 21.11.2017 20:03, Jake Petroules пишет: >> Hi Pavel, >> >> As the author and copyright holder, you're free to use whatever >> license you want. MIT is certainly a good choice. > Ok, this is great! > >> >> However, depending on the kind of functionality your modules provide, >> you may even like to upstream them to the Qbs project for inclusion >> in the official release. Perhaps you could upload the modules and we >> can take a look and see if it's a fit? > Xm, I do not think that you will find in my modules that it is really > valuable :)  These are just small utilities. I did not intend to > publish them, but so were the circumstances. > The modules are attached. > > -- > Pavel. > > P.S. > I work in the Russian-language segment, so all comments are in > Russian. If an incredible thing happens, and you like something, then > you are ready to make explanations in English. Sorry: "I" are ready to make explanations in English. > >> >> Cheers. >> >>> On Nov 21, 2017, at 3:10 AM, Карелин Павел wrote: >>> >>> Hi, guys! >>> >>> I wrote several modules that slightly extend the functionality of >>> QBS. I want to place them on GitHub, for using their in both open >>> source and commercial projects. Under what license should I place my >>> modules? >>> Can I use a MIT license? >>> >>> -- >>> BR, Pavel Karelin >>> >>> >>> _______________________________________________ >>> Qbs mailing list >>> Qbs at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/qbs > From chgans at gmail.com Wed Nov 22 05:42:23 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 22 Nov 2017 17:42:23 +1300 Subject: [Qbs] Tighter clang tooling integration In-Reply-To: <20171121104606.4f659984@ckandeler-archlinux> References: <99b79f62-ff40-7ae5-6fb7-f1991cba9bf3@gmail.com> <20171121104606.4f659984@ckandeler-archlinux> Message-ID: <9f3dc7fb-f9c9-0671-5c05-a165a26be0d5@gmail.com> On 21/11/2017 10:46 PM, Christian Kandeler wrote: > On Tue, 21 Nov 2017 18:01:32 +1300 Christian Gagneraud > wrote: > >> Qbs can generate a clang compilation database. Some (most) >> clang-based tools are not multi-cpu aware. >> >> For example a typical use of clang-check is cd repo.git qbs >> generate -g clangdb profile:someprofile # or cmake >> -DCMAKE_EXPORT_COMPILE_COMMANDS=ON find path/to/some/code -name >> '*.cpp' | xargs clang-check -analyze -p=someprofile As a side note, in my case CMake generate one database per "module" (lib, app, ...), whereas qbs generate a single database for the whole project. I do prefer the single database right now, but the one database per Qbs product could be interested too. The plugin could be improved by adding an optional product name on the command line. >> There are a few annoying things with this: - First you need to give >> clang-check which file you want to check - clang-check will process >> all the files one after another, even if you have multi CPU > > This one you can probably work around, e.g. using GNU parallel. Thanks for the tips! I wasn't aware of this one, maybe that's all I need (i'm looking for a simple solution). >> - find path/to/some/code -name '*.cpp' might retun files that >> should not be compiled. >> >> Wouldn't it be nice if we could ask qbs to run a clang-based tools >> on all the source files and with proper load distribution? >> >> Is this something that looks doable? Is it even wanted? > > This has come up before. It looked deceptively tempting at first to > just set the compiler to the clang tool and then "build" as normal, > but upon closer inspection, there were some issues. The most obvious > one would be that you'd have to somehow stop after the "compile" > step, but there were others as well (I forgot the details). If you Agree, it doesn't seems like the right approach even if sounds "easy" at first. > play around a bit in that area (perhaps with a dedicated module?), > you'll probably get more insight into where the problems lie. I could maybe use a custom Rule item, one that "transform" every .cpp file into, say a .clazy file (output of clazy on the .cpp file). But then i would have to tell qbs that i want a "master" file that depends on all the individual '.clazy' files. This still looks like a hack. Can't stop thinking of a 'qbs for-each-cpp somecommand --someflag {}' (similar to the 'find' and 'git for-each' commands) Chris From Jake.Petroules at qt.io Wed Nov 22 05:58:04 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 22 Nov 2017 04:58:04 +0000 Subject: [Qbs] Licensing of my own QBS modules In-Reply-To: <7e79e972-1463-cbbd-53cb-b611a1cb0080@yandex.ru> References: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> <7e79e972-1463-cbbd-53cb-b611a1cb0080@yandex.ru> Message-ID: <101A10BE-5FB3-4EAA-995D-36A646988174@qt.io> I took a quick look and: - protobuf module - there's actually an open issue for this (https://bugreports.qt.io/browse/QBS-563) so maybe you could take ownership ;) - cuda, gsoap... potentially useful, but I'm not that familiar with them - libs/... good, but set up in a way that seems fairly specific to your system. Could be useful if made more general I'm curious about your need for the functions in GccUtl. Why do you need the full path to libstdc++.a? And why gcc-ar instead of ar? It's possible we might want to make this configurable in Qbs, since there's an llvm-ar as well and there's presumably reasons a user might want to use the toolchain archiver vs the system archiver (same with the assembler). > On Nov 21, 2017, at 10:26 AM, Карелин Павел wrote: > > > > 21.11.2017 20:03, Jake Petroules пишет: >> Hi Pavel, >> >> As the author and copyright holder, you're free to use whatever license you want. MIT is certainly a good choice. > Ok, this is great! > >> >> However, depending on the kind of functionality your modules provide, you may even like to upstream them to the Qbs project for inclusion in the official release. Perhaps you could upload the modules and we can take a look and see if it's a fit? > Xm, I do not think that you will find in my modules that it is really valuable :) These are just small utilities. I did not intend to publish them, but so were the circumstances. > The modules are attached. > > -- > Pavel. > > P.S. > I work in the Russian-language segment, so all comments are in Russian. If an incredible thing happens, and you like something, then you are ready to make explanations in English. > >> >> Cheers. >> >>> On Nov 21, 2017, at 3:10 AM, Карелин Павел wrote: >>> >>> Hi, guys! >>> >>> I wrote several modules that slightly extend the functionality of QBS. I want to place them on GitHub, for using their in both open source and commercial projects. Under what license should I place my modules? >>> Can I use a MIT license? >>> >>> -- >>> BR, Pavel Karelin >>> >>> >>> _______________________________________________ >>> 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 hkarel at yandex.ru Wed Nov 22 10:43:07 2017 From: hkarel at yandex.ru (=?UTF-8?B?0JrQsNGA0LXQu9C40L0g0J/QsNCy0LXQuw==?=) Date: Wed, 22 Nov 2017 12:43:07 +0300 Subject: [Qbs] Licensing of my own QBS modules In-Reply-To: <101A10BE-5FB3-4EAA-995D-36A646988174@qt.io> References: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> <7e79e972-1463-cbbd-53cb-b611a1cb0080@yandex.ru> <101A10BE-5FB3-4EAA-995D-36A646988174@qt.io> Message-ID: <2cf70243-50c9-3d5d-d42f-53a9ccc755ee@yandex.ru> 22.11.2017 07:58, Jake Petroules пишет: > I took a quick look and: > > - protobuf module - there's actually an open issue for this (https://bugreports.qt.io/browse/QBS-563) so maybe you could take ownership ;) I created modules protobuf and cuda for building Caffe-Framework on QBS. Since I'm developing only C++/C, I'm not ready to take responsibility for the protobuf-generation for Python and Java. But I'm ready to provide an example (if of course you are interested) of building Caffe-Framework, so your can look at the work of modules protobuf and cuda.  It only takes me awhile to do it. > - cuda, gsoap... potentially useful, but I'm not that familiar with them Indeed, module cuda needs further work. It is necessary to refine some points, for example, replace "args.push ('- std = c ++ 11')" with a more general instruction. Nevertheless, the module is quite workable, it can probably be used as an example. The module gsoap - is my first attempt at creating modules for QBS. The gsoap generator has a rather complicated situation with the generation of namespaces. Therefore, I would not recommend this module for use, it needs serious revision > - libs/... good, but set up in a way that seems fairly specific to your system. In fact, it's just an agreement of the development team, which will be located some of the libraries used in the development process. On my previous work we supported about 10 OS (not the most recent versions - the billing primarily values stability). Therefore, there was such an arrangement: to place the relevant topical libraries in /opt. This approach proved to be quite viable on Linux and WIndows, for example: LibModule {     id: opencv     version: "3.0.x"     prefix: "/opt/opencv"     Properties {         condition: qbs.targetOS.contains("windows")                    && qbs.toolchain && qbs.toolchain.contains("mingw")         prefix: "c:/opt/opencv"         libSuffix: "/x86/mingw/lib"     } } But system libraries can also be used. For this, there is the useSystem flag. > Could be useful if made more general I do not really know which way to move here. If you give recommendations (ideas how to do it), then I will try to implement them. > > I'm curious about your need for the functions in GccUtl. Why do you need the full path to libstdc++.a? I do not need a path to the libstdc++.a :) But I need a path to the library libstdc++.so.6, provided that used the not system compiler. For example, I use /opt/gcc/5.4.0 and the system compiler gcc has version 4.8. Versions of the library  libstdc++.so.6 are incompatible with them. > And why gcc-ar instead of ar? The reason is the same - incompatibility of compilers. This does not always manifest itself, but I has already stepped on these rakes. > It's possible we might want to make this configurable in Qbs, since there's an llvm-ar as well and there's presumably reasons a user might want to use the toolchain archiver vs the system archiver (same with the assembler). > >> On Nov 21, 2017, at 10:26 AM, Карелин Павел wrote: >> >> >> >> 21.11.2017 20:03, Jake Petroules пишет: >>> Hi Pavel, >>> >>> As the author and copyright holder, you're free to use whatever license you want. MIT is certainly a good choice. >> Ok, this is great! >> >>> However, depending on the kind of functionality your modules provide, you may even like to upstream them to the Qbs project for inclusion in the official release. Perhaps you could upload the modules and we can take a look and see if it's a fit? >> Xm, I do not think that you will find in my modules that it is really valuable :) These are just small utilities. I did not intend to publish them, but so were the circumstances. >> The modules are attached. >> >> -- >> Pavel. >> >> P.S. >> I work in the Russian-language segment, so all comments are in Russian. If an incredible thing happens, and you like something, then you are ready to make explanations in English. >> >>> Cheers. >>> >>>> On Nov 21, 2017, at 3:10 AM, Карелин Павел wrote: >>>> >>>> Hi, guys! >>>> >>>> I wrote several modules that slightly extend the functionality of QBS. I want to place them on GitHub, for using their in both open source and commercial projects. Under what license should I place my modules? >>>> Can I use a MIT license? >>>> >>>> -- >>>> BR, Pavel Karelin >>>> >>>> >>>> _______________________________________________ >>>> Qbs mailing list >>>> Qbs at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/qbs >> From christian.kandeler at qt.io Wed Nov 22 11:17:57 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Wed, 22 Nov 2017 11:17:57 +0100 Subject: [Qbs] Tighter clang tooling integration In-Reply-To: <9f3dc7fb-f9c9-0671-5c05-a165a26be0d5@gmail.com> References: <99b79f62-ff40-7ae5-6fb7-f1991cba9bf3@gmail.com> <20171121104606.4f659984@ckandeler-archlinux> <9f3dc7fb-f9c9-0671-5c05-a165a26be0d5@gmail.com> Message-ID: <20171122111757.14e376d4@ckandeler-archlinux> On Wed, 22 Nov 2017 17:42:23 +1300 Christian Gagneraud wrote: > I could maybe use a custom Rule item, one that "transform" every .cpp > file into, say a .clazy file (output of clazy on the .cpp file). The interesting question here is how to get at the fully expanded command lines without code duplication. This code is in the compiler rules of the cpp module; that's why it appears that there needs to be some tight integration with that module. However, clazy for example is really just a compiler, so you can use it already today by simply setting cpp.compilerName to "clazy". > Can't stop thinking of a 'qbs for-each-cpp somecommand --someflag {}' > (similar to the 'find' and 'git for-each' commands) But this doesn't help you get the right flags. Christian From chgans at gmail.com Wed Nov 22 21:54:31 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Thu, 23 Nov 2017 09:54:31 +1300 Subject: [Qbs] Licensing of my own QBS modules In-Reply-To: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> References: <27970b58-b1d1-b08c-b4aa-d4d5134331ee@yandex.ru> Message-ID: On 22/11/2017 12:10 AM, Карелин Павел wrote: > Hi, guys! > > I wrote several modules that slightly extend the functionality of QBS. I > want to place them on GitHub, for using their in both open source and > commercial projects. Under what license should I place my modules? > Can I use a MIT license? Hi Pavel, Could you provide a link to your repo(s), this looks quite interesting. Chris > > -- > BR, Pavel Karelin > > > > > _______________________________________________ > Qbs mailing list > Qbs at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qbs > From chgans at gmail.com Thu Nov 23 01:00:56 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Thu, 23 Nov 2017 13:00:56 +1300 Subject: [Qbs] Question about linking (linux-gcc) Message-ID: <9752b401-04f1-affa-bea8-628f896cbf3d@gmail.com> Hi there, I have two questions related to the linking process, I'm using qbs-1.10 (as per QtC) on a Ubuntu 17.04 x86_32 VM. First the simple one: What is the best way to choose which binutils linker to use? I would like to activate the gold linker instead of the bfd one (default), gcc option for this is "-fuse-ld=gold", I think this option *has* to be passed to gcc, so i wonder if cpp.linkerFlags is the correct place, I know it works, but i'm curious to know if there's a better way to do it. My 2nd question requires a bit of explanation first: I need to link an app against lots of static libraries. Each static library has a list of Depends (mostly Qt deps). Qbs generate a link command for my app by simply appending all the libs' depends. So I endup with a very-very long command line that contains hundreds of duplicated Qt linking fragments. The actual link command is 49384 character longs! For some reason, it upset the linker (like the linker doesn't seem to simplify the command line), I have currently 4 link processes that have been running for more than half an hour, with qmake the link time is a couple of minutes with bfd, with qmake and the gold linker, the link time is roughly a minute or less (2.5 increase in speed). My static libraries qbs files are very-very simple, a file list, a Depends for Qt. I do not use (anymore) exported depends. Is it possible to work this around? I have the feeling that it might be due to the use of lto, as the g++ sub-process starts with: /usr/bin/ld -plugin .../liblto_plugin.co When I use the gold linker (with qbs) I do not have this problem, even tho the subprocess starts with /usr/bin/ld.gold -plugin .../liblto_plugin.co Any idea about that, is it a qbs issue or should I blame it on the bfd linker? Thanks, Chris PS: I am actually interested in evaluating LTO, but that's something that will come later (LTO is an expansive operation) From chgans at gmail.com Thu Nov 23 03:34:14 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Thu, 23 Nov 2017 15:34:14 +1300 Subject: [Qbs] Qbs and ccache (and QtC) Message-ID: <1a086443-afb3-9f41-c597-3536b823dd43@gmail.com> Hi there, QtC-4.5.0-rc1, qbs-1.10.0. I just tried to enable ccache in QtCreator, and qbs failed complaining it cannot find 'ar' and co. When i want to enable ccache, i use the export PATH=/usr/lib/ccache:$PATH trick (which is IMHO the "proper" way to deal with this on Linux). When i run QtC within this env, I can see new C/C++ compilers, eg. "GCC (C++, x86 32bit in /usr/lib/ccache)" along "GCC (C++, x86 32bit in /usr/bin)" - actually i'm not sure if they are auto-detected or if i set that up myself some time ago. I then clone my Qt profile, change the C/C++ compilers to use the ccache'd ones), and then simply rename the profile to "Qt X.Y (ccache)" When I select this Qt ccache'd profile, qbs complains that /usr/lib/ccache/ar doesn't exists. The problem seems to stem from Qbs trying to infer the path to 'ar' based on the path to gcc. Is this the right way to deal with ccache and QtC+Qbs? Should I open a bug report? On Qtc, Qbs or both? Chris From chgans at gmail.com Thu Nov 23 03:57:13 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Thu, 23 Nov 2017 15:57:13 +1300 Subject: [Qbs] Tighter clang tooling integration In-Reply-To: <20171122111757.14e376d4@ckandeler-archlinux> References: <99b79f62-ff40-7ae5-6fb7-f1991cba9bf3@gmail.com> <20171121104606.4f659984@ckandeler-archlinux> <9f3dc7fb-f9c9-0671-5c05-a165a26be0d5@gmail.com> <20171122111757.14e376d4@ckandeler-archlinux> Message-ID: <84062a64-b8c6-8077-90fe-b5b830f8e7b1@gmail.com> On 22/11/2017 11:17 PM, Christian Kandeler wrote: > On Wed, 22 Nov 2017 17:42:23 +1300 Christian Gagneraud > wrote: > >> I could maybe use a custom Rule item, one that "transform" every >> .cpp file into, say a .clazy file (output of clazy on the .cpp >> file). > > The interesting question here is how to get at the fully expanded > command lines without code duplication. This code is in the compiler > rules of the cpp module; that's why it appears that there needs to be > some tight integration with that module. The clang db plugin can do exactly that [1], so what about: jobqueue.start() for each project for each product for each group for each source command= userCommand(project.ruleCommands(product, source)) jobqueue.append(makeJob(command)) jobqueue.wait() ... Or something along these lines, i am not familiar with Qbs internals. > However, clazy for example > is really just a compiler, so you can use it already today by simply > setting cpp.compilerName to "clazy". OK, clazy might not be the best example, let's consider clang-check or clang-tidy then or any other (custom) clang-based tool not designed to be run this way. Chris [1] https://github.com/qbs/qbs/blob/master/src/plugins/generator/clangcompilationdb/clangcompilationdbgenerator.cpp#L70 From christian.kandeler at qt.io Thu Nov 23 10:52:58 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 23 Nov 2017 10:52:58 +0100 Subject: [Qbs] Qbs and ccache (and QtC) In-Reply-To: <1a086443-afb3-9f41-c597-3536b823dd43@gmail.com> References: <1a086443-afb3-9f41-c597-3536b823dd43@gmail.com> Message-ID: <20171123105258.3e0a1509@ckandeler-archlinux> On Thu, 23 Nov 2017 15:34:14 +1300 Christian Gagneraud wrote: > I just tried to enable ccache in QtCreator, and qbs failed complaining > it cannot find 'ar' and co. This should be fixed for 1.10. Earlier versions assumed the binutils to be at the same location as the compiler, so you have to manually set cpp.archiverPath there (also stripPath, objcopyPath and nmPath). > When i want to enable ccache, i use the export > PATH=/usr/lib/ccache:$PATH trick (which is IMHO the "proper" way to deal > with this on Linux). > > When i run QtC within this env, I can see new C/C++ compilers, eg. "GCC > (C++, x86 32bit in /usr/lib/ccache)" along "GCC (C++, x86 32bit in > /usr/bin)" - actually i'm not sure if they are auto-detected or if i set > that up myself some time ago. > I then clone my Qt profile, change the C/C++ compilers to use the > ccache'd ones), and then simply rename the profile to "Qt X.Y (ccache)" > > When I select this Qt ccache'd profile, qbs complains that > /usr/lib/ccache/ar doesn't exists. > The problem seems to stem from Qbs trying to infer the path to 'ar' > based on the path to gcc. > > Is this the right way to deal with ccache and QtC+Qbs? > Should I open a bug report? On Qtc, Qbs or both? Please double-check with an up to date version the tools. Note that an alternative way to use ccache with qbs is to use the real gcc and set cpp.compilerWrapper to ccache. Christian From christian.kandeler at qt.io Thu Nov 23 11:21:18 2017 From: christian.kandeler at qt.io (Christian Kandeler) Date: Thu, 23 Nov 2017 11:21:18 +0100 Subject: [Qbs] Question about linking (linux-gcc) In-Reply-To: <9752b401-04f1-affa-bea8-628f896cbf3d@gmail.com> References: <9752b401-04f1-affa-bea8-628f896cbf3d@gmail.com> Message-ID: <20171123112118.3a77c5cd@ckandeler-archlinux> On Thu, 23 Nov 2017 13:00:56 +1300 Christian Gagneraud wrote: > First the simple one: > What is the best way to choose which binutils linker to use? I would > like to activate the gold linker instead of the bfd one (default), gcc > option for this is "-fuse-ld=gold", I think this option *has* to be > passed to gcc, so i wonder if cpp.linkerFlags is the correct place, I > know it works, but i'm curious to know if there's a better way to do it. It's conceptually wrong, but will in practice work for C and C++ projects, because it's always the gcc/g++ executable that gets invoked. In 1.11, there will be cpp.driverLinkerFlags, which is the correct property for this. One might also think about introducing a dedicated convenience property for this. Not sure if it's worth it. > My 2nd question requires a bit of explanation first: > I need to link an app against lots of static libraries. Each static > library has a list of Depends (mostly Qt deps). > Qbs generate a link command for my app by simply appending all the libs' > depends. So I endup with a very-very long command line that contains > hundreds of duplicated Qt linking fragments. > The actual link command is 49384 character longs! Yes, this is an "interesting" problem. We cannot simply remove duplicate libraries, due to the way ld works. But there could still be a way to do some safe reductions there. You might want to create a task for that, preferably with a full example command line attached. > Is it possible to work this around? I can't think of anything right now. Since the linker does not fail outright, but is just very slow, I guess this problem is not the raw command line length, but the number of libraries, which seem to get processed over and over again. > I have the feeling that it might be due to the use of lto, as the g++ > sub-process starts with: /usr/bin/ld -plugin .../liblto_plugin.co > > When I use the gold linker (with qbs) I do not have this problem, even > tho the subprocess starts with /usr/bin/ld.gold -plugin .../liblto_plugin.co > > Any idea about that, is it a qbs issue or should I blame it on the bfd > linker? Well, I suppose both are trying a little less hard than they could be... Christian From Zhuravlev at rutoken.ru Thu Nov 23 15:42:56 2017 From: Zhuravlev at rutoken.ru (=?koi8-r?B?9tXSwdfMxdcg88XSx8XK?=) Date: Thu, 23 Nov 2017 14:42:56 +0000 Subject: [Qbs] building for iOS Message-ID: <0D5DF5BF6EC02C4D90A956EE7C51F814019AA316@AKTIV-MAIL.aktiv.guardant.ru> Hello, I ran into some problems while building for iOS: 1. Flag -syslibroot appears twice in the invocation of ld - one from the invocation of clang and one somewhere from the environment. When I try to run the whole clang command independently I get only one -syslibroot, the one from clang command. I suppose it's because the environment during the execution of qbs is different. So usually it's not a problem, but with bitcode enabled it becomes an issue: "only one -syslibroot is accepted for bitcode bundle for architecture arm64". So now I have to do the following in my qbs product: "cpp.syslibroot: undefined". Is there a better workaround for this? 2. I specify -fembed-bitcode flag and get the following warning from ld all the time: "-headerpad_max_install_names is ignored when used with -bitcode-bundle". -headerpad_max_install_names is linker flag that is inserted unconditionally. Is there an issue in bugtracker concerning this? 3. Framework flags are always duplicated. If I specify cpp.frameworks: ["Foundation"], clang's flags will be "-framework Foundation -framework Foundation". Is it really messy qbs behavior, or am I doing something wrong? I would also like to discuss following features that could be added to qbs: 1. Ability to copy framework into Frameworks folder of application bundle (Xcode has this feature). When an application uses custom framework, there could be an option to put framework bundle into the application bundle. 2. Reproducing Apple framework bundle structure for iOS. I use macOS 10.12.6, XCode 9.0.1. _ Sergey -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Fri Nov 24 01:00:58 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Fri, 24 Nov 2017 13:00:58 +1300 Subject: [Qbs] Qbs and ccache (and QtC) In-Reply-To: <20171123105258.3e0a1509@ckandeler-archlinux> References: <1a086443-afb3-9f41-c597-3536b823dd43@gmail.com> <20171123105258.3e0a1509@ckandeler-archlinux> Message-ID: On 23/11/2017 10:52 PM, Christian Kandeler wrote: > On Thu, 23 Nov 2017 15:34:14 +1300 Christian Gagneraud > wrote: > >> I just tried to enable ccache in QtCreator, and qbs failed >> complaining it cannot find 'ar' and co. > > This should be fixed for 1.10. Earlier versions assumed the binutils > to be at the same location as the compiler, so you have to manually > set cpp.archiverPath there (also stripPath, objcopyPath and nmPath). Good to know, thanks. I will wait for qbs-1.10. >> Is this the right way to deal with ccache and QtC+Qbs? Should I >> open a bug report? On Qtc, Qbs or both? > > Please double-check with an up to date version the tools. Note that > an alternative way to use ccache with qbs is to use the real gcc and > set cpp.compilerWrapper to ccache. I think i'll use that in the mean time, I should be able to set that in the "Additional Qbs Profile Settings" of a kit. Thanks a lot, Chris From Jake.Petroules at qt.io Sun Nov 26 23:17:58 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Sun, 26 Nov 2017 22:17:58 +0000 Subject: [Qbs] building for iOS In-Reply-To: <0D5DF5BF6EC02C4D90A956EE7C51F814019AA316@AKTIV-MAIL.aktiv.guardant.ru> References: <0D5DF5BF6EC02C4D90A956EE7C51F814019AA316@AKTIV-MAIL.aktiv.guardant.ru> Message-ID: <065F2FFD-EAF6-4CC7-A322-9A5BACC76C63@qt.io> > On Nov 23, 2017, at 6:42 AM, Журавлев Сергей wrote: > > Hello, > > I ran into some problems while building for iOS: > > 1. Flag -syslibroot appears twice in the invocation of ld - one from the invocation of clang and one somewhere from the environment. When I try to run the whole clang command independently I get only one -syslibroot, the one from clang command. I suppose it's because the environment during the execution of qbs is different. So usually it's not a problem, but with bitcode enabled it becomes an issue: "only one -syslibroot is accepted for bitcode bundle for architecture arm64". So now I have to do the following in my qbs product: "cpp.syslibroot: undefined". Is there a better workaround for this? > > 2. I specify -fembed-bitcode flag and get the following warning from ld all the time: "-headerpad_max_install_names is ignored when used with -bitcode-bundle". -headerpad_max_install_names is linker flag that is inserted unconditionally. Is there an issue in bugtracker concerning this? Bitcode isn't yet supported in Qbs, but there's now an open task for this: https://bugreports.qt.io/browse/QBS-1251 Both problems you note (#1 and #2) will be resolved when support is added. > 3. Framework flags are always duplicated. If I specify cpp.frameworks: ["Foundation"], clang's flags will be "-framework Foundation -framework Foundation". Is it really messy qbs behavior, or am I doing something wrong? You're not doing anything wrong. This "issue" affects regular libraries as well as frameworks. Basically, the list of linked libraries is order-sensitive so it's possible that any attempt by us to deduplicate the list of linked libraries could cause a problem. > I would also like to discuss following features that could be added to qbs: > > 1. Ability to copy framework into Frameworks folder of application bundle (Xcode has this feature). When an application uses custom framework, there could be an option to put framework bundle into the application bundle. This is a known issue. Implementing this properly has required the implementation of new engine primitives. Now that those are in place, we can begin to add the feature. It's on the todo list: https://bugreports.qt.io/browse/QBS-643 > 2. Reproducing Apple framework bundle structure for iOS. This is largely already in place. What specific issues are you running into? > I use macOS 10.12.6, XCode 9.0.1. > > _ > Sergey > _______________________________________________ > 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 Zhuravlev at rutoken.ru Mon Nov 27 10:00:57 2017 From: Zhuravlev at rutoken.ru (=?utf-8?B?0JbRg9GA0LDQstC70LXQsiDQodC10YDQs9C10Lk=?=) Date: Mon, 27 Nov 2017 09:00:57 +0000 Subject: [Qbs] building for iOS Message-ID: <0D5DF5BF6EC02C4D90A956EE7C51F814019AA70C@AKTIV-MAIL.aktiv.guardant.ru> >> I would also like to discuss following features that could be added to qbs: >> 2. Reproducing Apple framework bundle structure for iOS. > This is largely already in place. What specific issues are you running into? If I understand correctly, option bundle.isShallow allows to reproduce non-shallow structures. But it is read only and for macOS only. _ Sergey From Jake.Petroules at qt.io Mon Nov 27 19:25:05 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 27 Nov 2017 18:25:05 +0000 Subject: [Qbs] building for iOS In-Reply-To: <0D5DF5BF6EC02C4D90A956EE7C51F814019AA70C@AKTIV-MAIL.aktiv.guardant.ru> References: <0D5DF5BF6EC02C4D90A956EE7C51F814019AA70C@AKTIV-MAIL.aktiv.guardant.ru> Message-ID: <8DFCB33B-8E5D-4198-AB59-21620E7048EA@qt.io> > On Nov 27, 2017, at 1:00 AM, Журавлев Сергей wrote: > >>> I would also like to discuss following features that could be added to qbs: >>> 2. Reproducing Apple framework bundle structure for iOS. > >> This is largely already in place. What specific issues are you running into? > > If I understand correctly, option bundle.isShallow allows to reproduce non-shallow structures. But it is read only and for macOS only. bundle.isShallow controls whether the bundle is a normal layout (like on macOS) or a "shallow" (flat) layout like on iOS. It's read only because there is virtually no reason why you'd want to change this. What is the use case? > _ > Sergey > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From chgans at gmail.com Mon Nov 27 22:22:54 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 28 Nov 2017 10:22:54 +1300 Subject: [Qbs] Qt doc, qtmain and qbs Message-ID: Hi there, I was looking at the usage of the qtmain static library (on Windows), i wasn't aware of this, so i looked up the Qt documentation and it says: qtmain is a helper library that enables the developer to write a cross-platform main() function on Windows. If you do not use qmake or other build tools such as CMake, then you need to link against the qtmain library. Shouldn't qbs be in the build tools list too, eg: "If you do not use qmake, qbs or other build tools such as CMake" Is it worth creating a Qt ticket (and a change request)? Is so, are you happy with the above phrasing? Chris PS: Congrats for the new online Qbs documentation! From Jake.Petroules at qt.io Tue Nov 28 00:16:17 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 27 Nov 2017 23:16:17 +0000 Subject: [Qbs] Qt doc, qtmain and qbs In-Reply-To: References: Message-ID: <510FEA11-72F9-447C-91D2-A46923FE9EAA@qt.io> > On Nov 27, 2017, at 1:22 PM, Christian Gagneraud wrote: > > Hi there, > > I was looking at the usage of the qtmain static library (on Windows), i wasn't aware of this, so i looked up the Qt documentation and it says: > > qtmain is a helper library that enables the developer to write a cross-platform main() function on Windows. If you do not use qmake or other build tools such as CMake, then you need to link against the qtmain library. > > > Shouldn't qbs be in the build tools list too, eg: "If you do not use qmake, qbs or other build tools such as CMake" > > Is it worth creating a Qt ticket (and a change request)? Is so, are you happy with the above phrasing? Yes, and yes. > Chris > > PS: Congrats for the new online Qbs documentation! Thanks! :) > _______________________________________________ > 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 Tue Nov 28 03:38:36 2017 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 28 Nov 2017 15:38:36 +1300 Subject: [Qbs] Qt doc, qtmain and qbs In-Reply-To: <510FEA11-72F9-447C-91D2-A46923FE9EAA@qt.io> References: <510FEA11-72F9-447C-91D2-A46923FE9EAA@qt.io> Message-ID: <9e9d6a7c-8fe7-6a11-4d1a-2bedbd14d66e@gmail.com> On 28/11/2017 12:16 PM, Jake Petroules wrote: >> Shouldn't qbs be in the build tools list too, eg: "If you do not >> use qmake, qbs or other build tools such as CMake" >> >> Is it worth creating a Qt ticket (and a change request)? Is so, are >> you happy with the above phrasing? > > Yes, and yes. For the first yes: https://bugreports.qt.io/browse/QTBUG-64803 Chris From Zhuravlev at rutoken.ru Tue Nov 28 10:09:08 2017 From: Zhuravlev at rutoken.ru (=?utf-8?B?0JbRg9GA0LDQstC70LXQsiDQodC10YDQs9C10Lk=?=) Date: Tue, 28 Nov 2017 09:09:08 +0000 Subject: [Qbs] building for iOS In-Reply-To: <8DFCB33B-8E5D-4198-AB59-21620E7048EA@qt.io> References: <0D5DF5BF6EC02C4D90A956EE7C51F814019AA70C@AKTIV-MAIL.aktiv.guardant.ru> <8DFCB33B-8E5D-4198-AB59-21620E7048EA@qt.io> Message-ID: <0D5DF5BF6EC02C4D90A956EE7C51F814019AB210@AKTIV-MAIL.aktiv.guardant.ru> >bundle.isShallow controls whether the bundle is a normal layout (like on macOS) or a "shallow" (flat) layout like on iOS. It's read only because >there is virtually no reason why you'd want to change this. >What is the use case? Does framework bundle have "shallow" structure on iOS? The only information from Apple about framework bundle structure I found says that "The creation of custom frameworks is not supported in iOS". The only suggested framework bundle structure is "non-shallow". https://developer.apple.com/go/?id=bundle-structure _ Sergey From Jake.Petroules at qt.io Tue Nov 28 10:20:40 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 28 Nov 2017 09:20:40 +0000 Subject: [Qbs] building for iOS In-Reply-To: <0D5DF5BF6EC02C4D90A956EE7C51F814019AB210@AKTIV-MAIL.aktiv.guardant.ru> References: <0D5DF5BF6EC02C4D90A956EE7C51F814019AA70C@AKTIV-MAIL.aktiv.guardant.ru> <8DFCB33B-8E5D-4198-AB59-21620E7048EA@qt.io> <0D5DF5BF6EC02C4D90A956EE7C51F814019AB210@AKTIV-MAIL.aktiv.guardant.ru> Message-ID: The notice "The creation of custom frameworks is not supported in iOS" is ancient history. This article was written long before iOS 8 was released and Apple forgot to update it. You should file a radar so they can be made aware of, and fix it. Frameworks don't have shallow structure on iOS but as a Qbs developer you should not concern yourself with this; Qbs will take care of creating the proper structure for you. Just use: DynamicLibrary { Depends { name: "bundle" } bundle.isBundle: true files: ... } In BundleModule.qbs you can also see a bunch of properties after a comment "all paths are relative to the directory containing the bundle"; you can use these to determine the path to install files into. There will be better recommendations in the documentation in the future as to how to create macOS and iOS frameworks. > On Nov 28, 2017, at 1:09 AM, Журавлев Сергей wrote: > >> bundle.isShallow controls whether the bundle is a normal layout (like on macOS) or a "shallow" (flat) layout like on iOS. It's read only because >there is virtually no reason why you'd want to change this. > >> What is the use case? > > Does framework bundle have "shallow" structure on iOS? The only information from Apple about framework bundle structure I found says that "The creation of custom frameworks is not supported in iOS". The only suggested framework bundle structure is "non-shallow". https://developer.apple.com/go/?id=bundle-structure > > _ > Sergey > -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Jake.Petroules at qt.io Wed Nov 29 18:21:46 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 29 Nov 2017 17:21:46 +0000 Subject: [Qbs] qbs adds flags, that interrupt building in case of conflicting flags In-Reply-To: <1509036770.164263866@f464.i.mail.ru> References: <1509036770.164263866@f464.i.mail.ru> Message-ID: <63683522-B4B3-4F77-858D-008367473830@qt.io> Known issue. https://bugreports.qt.io/browse/QBS-1251 > On Oct 26, 2017, at 9:52 AM, Сергей via Qbs wrote: > > So i compile for ios and add this -fembed-bitcode flag to the linker. It is incompatible with -undefined, which is added unconditionally by qbs on darwin platforms. Bitcode is a requirement from apple store. Also -headerpad-max-install-names pproduces a warning when used with bitcode flag. > > Any thoughts? > _______________________________________________ > 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 Jake.Petroules at qt.io Wed Nov 29 18:23:31 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 29 Nov 2017 17:23:31 +0000 Subject: [Qbs] Is Qbs build tool available for Android & iOS? In-Reply-To: References: Message-ID: <4199ABCC-B96D-4678-8463-14B7CD908C14@qt.io> Qbs does support iOS and Android... there are many features which are not yet finished, and the Qt Creator integration is one of the major ones. Are you able to compile the project on the command line? > On Sep 11, 2017, at 5:27 AM, Programcı Kanguru wrote: > > Hi; I installed Qt 5.9.1 + Qt Creator 4.4.0. I created a QQC2 project with Qbs 1.9. I can compile my project for Linux desktop but I can't compile it for Android x86 / armv7. Also I can compile the project with qmake for Linux desktop and Android. Android SDK and other tools are installed. When I changed platform as Android, my project's some parts are disabled like this: > > ??? Thanks. > _______________________________________________ > 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 Nov 30 23:45:51 2017 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Thu, 30 Nov 2017 23:45:51 +0100 Subject: [Qbs] How to set GCC optimization -O3 in releasebuilds? Message-ID: Hi all, 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. 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? Best regards, Ola Røer Thorsen -------------- next part -------------- An HTML attachment was scrubbed... URL: