Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

I was using CMake for several years (and still forced to use it now), however i moved all my projects to QBS for one reason - CMake is too complex. It has great documentation, but it can't be used without it; on the contrary, qbs is very intuitive. I don't have to remember tons of variables like

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 2016-09-20 15:18, Konstantin Tokarev wrote: > 20.09.2016, 22:11, "Matthew Woehlke" : >> That works with e.g. make/ninja, but not so well with VS, but that's a >> VS failing that I don't see how Qbs could overcome, given that VS *is* >> the build tool and doesn't AFAIK

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

20.09.2016, 22:21, "Matthew Woehlke" : > On 2016-09-15 02:57, Oswald Buddenhagen wrote: >>  On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development >> wrote: >>>  I want to understand Qbs and what it can do with a dynamic build graph >>>  which CMake

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

> On Sep 20, 2016, at 12:18 PM, Konstantin Tokarev wrote: > > > > 20.09.2016, 22:11, "Matthew Woehlke" : >> That works with e.g. make/ninja, but not so well with VS, but that's a >> VS failing that I don't see how Qbs could overcome, given that VS

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 2016-09-15 02:57, Oswald Buddenhagen wrote: > On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote: >> I want to understand Qbs and what it can do with a dynamic build graph >> which CMake can't do. > > there is no such thing, as after full expansion the graph has to be

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

20.09.2016, 22:11, "Matthew Woehlke" : > That works with e.g. make/ninja, but not so well with VS, but that's a > VS failing that I don't see how Qbs could overcome, given that VS *is* > the build tool and doesn't AFAIK support dynamic build graphs. QBS does not use

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 2016-09-08 07:41, Bo Thorsen wrote: > Den 05-09-2016 kl. 20:49 skrev Milian Wolff: >>> As an incredibly simple example, make is inherently limited in that it >>> cannot even represent a rule with multiple outputs (there are some >>> workarounds, but they are hacky and rather limited in how they

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 16/09/16 03:07, Christian Kandeler wrote: Stephen Kelly wrote: My previous guess about Qbs being able to generate unknown files in a particular location and then determine them by an 'ls' equivalent, moc them and compile everything is not something Qbs would be able to do. I'm having

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Stephen Kelly wrote: > My previous guess about Qbs being able to generate unknown files in a > particular location and then determine them by an 'ls' equivalent, moc > them and compile everything is not something Qbs would be able to do. I'm having trouble parsing this, but if you mean that

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 15/09/16 08:57, Oswald Buddenhagen wrote: On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote: I want to understand Qbs and what it can do with a dynamic build graph which CMake can't do. there is no such thing Oh, I'm very surprised by that. That also means

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Wed, Sep 14, 2016 at 12:05:15PM +0200, Stephen Kelly via Development wrote: > I want to understand Qbs and what it can do with a dynamic build graph > which CMake can't do. > there is no such thing, as after full expansion the graph has to be static by definition (the output artifacts are

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 13/09/16 22:29, Christian Kandeler wrote: Stephen Kelly wrote: There is no input file. There is only an input number. The task is from Bo, who gave it as a simplified example. Oops, I'm wrong here. Bo said to read the number from a file. I don't think that changes anything though

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Stephen Kelly wrote: >> There is no input file. There is only an input number. The task is from >> Bo, who gave it as a simplified example. > Oops, I'm wrong here. Bo said to read the number from a file. > I don't think that changes anything though regarding dynamic build graph > being an

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Stephen Kelly wrote: > Christian Kandeler wrote: > >> [Sorry about the formatting, using outlook] >> >> Stephen Kelly wrote: >>> Here's the CMake version: >> >> [ ... ] >> >>> execute_process( >>> COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list >>>

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Konstantin Tokarev wrote: >> -Qbs has great features that you can't find in other build systems (e.g. >> it can build multiple ABIs/platforms at once). > > For the record, premake can do it as well. Can you show me the syntax for this with premake (and with Qbs)? I assume you're talking about

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Christian Kandeler wrote: > [Sorry about the formatting, using outlook] > > Stephen Kelly wrote: >> Here's the CMake version: > > [ ... ] > >> execute_process( >> COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list >> ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 >>

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Sep 13, 2016, at 12:10 PM, Christian Kandeler > wrote: [Sorry about the formatting, using outlook] Stephen Kelly wrote: > Here's the CMake version: [ ... ] > execute_process( > COMMAND python

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Sorry about the formatting, using outlook] Stephen Kelly wrote: > Here's the CMake version: [ ... ] > execute_process( > COMMAND python ${CMAKE_CURRENT_SOURCE_DIR}/generator.py --list > ${CMAKE_CURRENT_BINARY_DIR}/genoutput 5 > OUTPUT_VARIABLE fileList > ) How do you know

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Hi Edward, You copied the line: (Stephen) "In reality, rewriting Qt's build system in CMake will actually be a PITA, and will require changes to CMake to make everything better" That was a stenography error. Can you remove it? Thanks, On 12/09/16 16:08, Edward Welbourne wrote:

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

For reference, I've turned Andrew's notes (see ur-ancestor post of this thread) into: https://wiki.qt.io/Qt_build_systems_at_QtCon_2016 Eddy. ___ Development mailing list Development@qt-project.org

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 08/09/16 14:34, Christian Kandeler wrote: On 09/08/2016 02:03 PM, Bo Thorsen wrote: Ok, go try it. Create a simple python or perl script that reads a file. The file just has a single number N inside it. And based on N the script outputs those files: Here's the CMake version:

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 08/09/16 14:34, Christian Kandeler wrote: On 09/08/2016 02:03 PM, Bo Thorsen wrote: Ok, go try it. Create a simple python or perl script that reads a file. The file just has a single number N inside it. And based on N the script outputs those files: Here's the CMake version:

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On joi, 8 septembrie 2016 20:22:25 EEST Jake Petroules wrote: > I just found a perfect example of how hard building a JAR file is in qmake > for example, compared to qbs: IMHO will be even easier if instead: qbs-javac-scan.qbs: [...] files: [ "io/qt/qbs/**/*.java" ] [...] You'll

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Bo Thorsen wrote: > I'm sure there are ways you can make the build call cmake or force a > build to fail and rebuild, and that's what you can currently do. And > those all feels annoying when you work on the project. Well, that's what CMake does by itself whenever it sees that it's needed (or at

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

I just found a perfect example of how hard building a JAR file is in qmake for example, compared to qbs: qbs-javac-scan.pro Description: qbs-javac-scan.pro qbs-javac-scan.qbs Description: qbs-javac-scan.qbs And the qmake version technically doesn't even handle dependencies properly (e.g.

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Jake Petroules wrote: > Another thing that's very hard to do in other build systems is building > Java code. The class files emitted by a Java compiler actually vary > depending on the contents of the Java files themselves. > > Imagine you've built a JAR file, and then you add a new anonymous

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Another thing that's very hard to do in other build systems is building Java code. The class files emitted by a Java compiler actually vary depending on the contents of the Java files themselves. Imagine you've built a JAR file, and then you add a new anonymous inner class within one of your

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 08/09/16 14:48, Milian Wolff wrote: Someone else also told me that this is apparently harder then I thought it is with CMake, when the name of the output files of a code generator is not known. It is possible, but far from easy esp. when you don't have control over the generator script

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Den 08-09-2016 kl. 14:19 skrev Konstantin Tokarev: > The only problem is that you have to run moc on each of the .h files. Run moc from inside script when you generate header. Yes, I thought about that at the time as well. While simple enpough, there are some complications. You would have to

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Donnerstag, 8. September 2016 14:03:05 CEST Bo Thorsen wrote: > Den 08-09-2016 kl. 13:47 skrev Milian Wolff: > > On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote: > >> Den 05-09-2016 kl. 20:49 skrev Milian Wolff: > As an incredibly simple example, make is inherently limited

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 09/08/2016 02:03 PM, Bo Thorsen wrote: > Ok, go try it. Create a simple python or perl script that reads a file. > The file just has a single number N inside it. And based on N the script > outputs those files: > > server.h > method1.h > method2.h > ... > methodN.h > > Inside method1.h you

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

08.09.2016, 15:03, "Bo Thorsen" : > Den 08-09-2016 kl. 13:47 skrev Milian Wolff: >>  On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote: >>>  Den 05-09-2016 kl. 20:49 skrev Milian Wolff: >  As an incredibly simple example, make is inherently limited in that

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Den 08-09-2016 kl. 13:47 skrev Milian Wolff: On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote: Den 05-09-2016 kl. 20:49 skrev Milian Wolff: As an incredibly simple example, make is inherently limited in that it cannot even represent a rule with multiple outputs (there are some

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Donnerstag, 8. September 2016 13:41:21 CEST Bo Thorsen wrote: > Den 05-09-2016 kl. 20:49 skrev Milian Wolff: > >> As an incredibly simple example, make is inherently limited in that it > >> > >> > cannot even represent a rule with multiple outputs (there are some > >> > workarounds, but they

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Den 05-09-2016 kl. 20:49 skrev Milian Wolff: As an incredibly simple example, make is inherently limited in that it > cannot even represent a rule with multiple outputs (there are some > workarounds, but they are hacky and rather limited in how they can be > applied). And ninja is no magic

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 7 September 2016 at 01:47, Viktor Engelmann wrote: > > Am 06.09.2016 um 06:52 schrieb Ch'Gans: > > On 6 September 2016 at 16:20, Thiago Macieira > wrote: > > Which is, in itself, an argument: why learn yet

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Keeping discussion posted on ML] On 7 September 2016 at 20:08, Viktor Engelmann wrote: > Really? I haven't checked out Qbs yet, but that sounds like the build > system I was looking for. > > So maybe I don't have to write my own build tool after all :-D > Give it a try,

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

07.09.2016, 14:17, "BogDan Vatra" : > On marți, 6 septembrie 2016 17:35:03 EEST Cristian Adam wrote: >>  On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: >>  > I guess somebody could even get CMake to write Qbs files, it would just be >>  > one more

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On marți, 6 septembrie 2016 17:35:03 EEST Cristian Adam wrote: > On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: > > I guess somebody could even get CMake to write Qbs files, it would just be > > one more generator. :-) > > This was done already >

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

I don't think the joke is racist or sexist. The protagonists happen to be female, but the gender has nothing to do with the punchline (at least I don't think so). I have read the same joke with blond men and with clerks. You could take anyone - and that is what makes the joke in-offensive for

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 06/09/16 20:30, Cristian Adam wrote: Maybe "bad feedback" is strong, but it was non constructive and lead to the removal of the Qbs generator. To clarify even further: the contribution was wip, the contributor was surprised at it being merged, and happy with it being reverted:

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 06/09/16 20:30, Cristian Adam wrote: Maybe "bad feedback" is strong, but it was non constructive and lead to the removal of the Qbs generator. To clarify even further: the contribution was wip, the contributor was surprised at it being merged, and happy with it being reverted:

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Tue, Sep 6, 2016 at 5:14 PM, Kevin Kofler wrote: > > I guess somebody could even get CMake to write Qbs files, it would just be > one more generator. :-) > > This was done already ,

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

06.09.2016, 18:24, "Jake Petroules" : >> On Sep 6, 2016, at 5:14 PM, Kevin Kofler wrote: >> >> Ch'Gans wrote: >>> I never wanted to use CMake b/c for me it look like a gross hack >>> (Reminds me of GNU M4). >> >> The CMake language is much easier to

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Sep 6, 2016, at 5:14 PM, Kevin Kofler > wrote: Ch'Gans wrote: I never wanted to use CMake b/c for me it look like a gross hack (Reminds me of GNU M4). The CMake language is much easier to use than m4, and also there is just one layer

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Ch'Gans wrote: > I never wanted to use CMake b/c for me it look like a gross hack > (Reminds me of GNU M4). The CMake language is much easier to use than m4, and also there is just one layer rather than having autoconf on top of m4, with shell script snippets mixed in. There is a reason CMake

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Ch'Gans wrote: > If I followed this reasoning, I would still be writing my programs in > Motorola assembler... pea msg(%pc) jbsr puts addq.l #4,%a7 rts msg: .asciz "And this would be wrong, why? ;-)" or if you prefer the more traditional syntax: pea msg(PC) jsr puts addq.l #4,a7 rts msg:

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em terça-feira, 6 de setembro de 2016, às 14:00:55 PDT, Laszlo Agocs escreveu: > Using one "bin" is the default behavior, yes, but one can pass -hostprefix > to separate them upon install. > > > http://doc-snapshots.qt.io/qt5-5.8/embedded-linux.html#configuring-a-specifi > c-device That's for

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

It kind of reminds me of this joke: http://www.ebaumsworld.com/jokes/blond-hole-diggers/80432143/ Do we have a policy about inappropriate content posted to mailing lists and similar communication channels? If not, I think we should agree on banning at least some basic things like racism or

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

+laszlo.agocs=qt...@qt-project.org> on behalf of Thiago Macieira <thiago.macie...@intel.com> Sent: Tuesday, September 6, 2016 3:49 PM To: development@qt-project.org Subject: Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016 Em terça-feira, 6 de setembro de 2016,

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em terça-feira, 6 de setembro de 2016, às 06:20:34 PDT, Thiago Macieira escreveu: > Building the host tools while cross-compiling is a convenience and I think > we can keep it, but I don't think we should simply have different "bin" > dirs. Fail in sentence rewrite. I wanted to write "don't

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Am 06.09.2016 um 06:52 schrieb Ch'Gans: > On 6 September 2016 at 16:20, Thiago Macieira > wrote: >> Which is, in itself, an argument: why learn yet another buildsystem? > ... > > Why learn yet another programming language? > > ... > > An average software developer

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em terça-feira, 6 de setembro de 2016, às 16:52:47 PDT, Ch'Gans escreveu: > > Which is, in itself, an argument: why learn yet another buildsystem? > > Good question, maybe because it's more powerful, it fits better your > needs, it is more fun, it uses new concepts, ... > Or just out of

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em terça-feira, 6 de setembro de 2016, às 11:46:12 PDT, Stephen Kelly via Development escreveu: > > Whenever you cross-compile Qt, you end up with tools that can only be run > > on the host. So Qt's cross-compilation mechanism can't be used to build > > tools that can be run on the target

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 06/09/16 02:13, Thiago Macieira wrote: Em segunda-feira, 5 de setembro de 2016, às 12:40:54 PDT, Stephen Kelly via Development escreveu: I think something was lost in transit on this point. I don’t think it would be a PITA to write a CMake buildsystem for Qt. I recall the above point was

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 09/06/16 03:08, Thiago Macieira wrote: Em segunda-feira, 5 de setembro de 2016, às 12:49:03 PDT, Andrew Knight escreveu: ** General sentiment: - As long as Qbs looks like a part of Qt, it is perceived as a Qt product, and is less attractive to external users. - Yet, there remains a conflict:

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 6 September 2016 at 16:20, Thiago Macieira wrote: > Em terça-feira, 6 de setembro de 2016, às 13:40:40 PDT, Ch'Gans escreveu: >> On 6 September 2016 at 01:52, Konstantin Tokarev wrote: >> > 05.09.2016, 16:38, "Kevin Kofler"

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em terça-feira, 6 de setembro de 2016, às 13:40:40 PDT, Ch'Gans escreveu: > On 6 September 2016 at 01:52, Konstantin Tokarev wrote: > > 05.09.2016, 16:38, "Kevin Kofler" : > >> Andrew Knight wrote: > >>> * Quick survey: which build system do you use

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 6 September 2016 at 01:52, Konstantin Tokarev wrote: > 05.09.2016, 16:38, "Kevin Kofler" : >> Andrew Knight wrote: >>> * Quick survey: which build system do you use (raise of hands by ~40 >>> people) >>> - CMake ~70% >>> - qmake ~20% >>> - Qbs

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 5 September 2016 at 23:08, NIkolai Marchenko wrote: > Been using QBS for the last 6 months, transformed all projects to it(from > qmake). Never looked back. > It just clicks for me. Most everything seems logical (if poorly explained) > when you understand how to do it.

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em segunda-feira, 5 de setembro de 2016, às 14:12:23 PDT, Jake Petroules escreveu: > Many of you seem to not understand how complex build tools can get and just > how simple Qbs can make problems that are incredibly challenging in other > systems. Perhaps you should actually try Qbs before

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em segunda-feira, 5 de setembro de 2016, às 12:40:54 PDT, Stephen Kelly via Development escreveu: > I think something was lost in transit on this point. I don’t think it would > be a PITA to write a CMake buildsystem for Qt. I recall the above point was > in reference to ‘compiling host tools and

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Em segunda-feira, 5 de setembro de 2016, às 12:49:03 PDT, Andrew Knight escreveu: > ** General sentiment: > - As long as Qbs looks like a part of Qt, it is perceived as a Qt > product, and is less attractive to external users. > - Yet, there remains a conflict: "if Qt doesn't use it, I don't

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Montag, 5. September 2016 14:12:23 CEST Jake Petroules wrote: > On Sep 5, 2016, at 3:38 PM, Kevin Kofler > > wrote: > - (Milian) CMakeis used by e.g. clang and it works for them > > … and the whole stack of software from the KDE project,

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Sep 5, 2016, at 4:12 PM, Jake Petroules > wrote: On Sep 5, 2016, at 3:38 PM, Kevin Kofler > wrote: - (Milian) CMakeis used by e.g. clang and it works for them … and the whole stack of

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Sep 5, 2016, at 3:38 PM, Kevin Kofler > wrote: - (Milian) CMakeis used by e.g. clang and it works for them … and the whole stack of software from the KDE project, and other large projects. Keep in mind that "large projects use X,

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

05.09.2016, 16:38, "Kevin Kofler" : > Andrew Knight wrote: >>  - (Tobias) Cmake is the "worst" system in Qt Creator because CMake >>  doesn't give enough feedback to the IDE. We need first-class support for >>  CMake in Qt Creator, though, so that is irrelevant to the

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Andrew Knight wrote: > - (Tobias) Cmake is the "worst" system in Qt Creator because CMake > doesn't give enough feedback to the IDE. We need first-class support for > CMake in Qt Creator, though, so that is irrelevant to the discussion of > which system we use to build Qt. Anything you can get

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Hi Steve, On 09/05/16 15:40, Stephen Kelly wrote: - (Stephen) "In reality, rewriting Qt's build system in CMake will actually be a PITA, and will require changes to CMake to make everything better" I think something was lost in transit on this point. I don’t think it would be a PITA to

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Thanks Andrew for these notes! You did really well to capture the key points from a complex and meandering discussion. >- (Stephen) "In reality, rewriting Qt's build system in CMake will >actually be a PITA, and will require changes to CMake to make everything >better" I think something

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On Mon, Sep 5, 2016 at 12:27 PM, Sune Vuorela wrote: > On 2016-09-05, Andrew Knight wrote: > > tl;dr: Lots of discussion on the merits of which build system (CMake, > > Qbs) should replace qmake in building Qt; lots of supporters of CMake > > but

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

Been using QBS for the last 6 months, transformed all projects to it(from qmake). Never looked back. It just clicks for me. Most everything seems logical (if poorly explained) when you understand how to do it. One thing QBS needs is better documentation, because a lot of things that are

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

On 2016-09-05, Andrew Knight wrote: > tl;dr: Lots of discussion on the merits of which build system (CMake, > Qbs) should replace qmake in building Qt; lots of supporters of CMake > but no volunteers to do the work, many reasons to use Qbs as well. Some I do think

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

I really want to move to QBS, because of its advantages (speed, good dependency tracking, nice syntax, fexibility). However, as long as Qt-Creator keeps generating new projects using qmake templates, I am not so confident in the future of QBS. Also, if QBS is not used for all own projects, my