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 CM

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 support dynamic build graph

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 can't do. >> >>  there is no

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 *is* >> the build tool and doesn't AFAIK suppo

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 VS as a build tool, it is no

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 trou

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 you

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 I

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 expect

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

13.09.2016, 23:00, "Stephen Kelly" : > 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 prema

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 regarding

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 advanta

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 >>> ${CMAKE_CURRENT_BIN

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 b

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 >> OUTPUT

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

On Sep 13, 2016, at 12:10 PM, Christian Kandeler mailto:christian.kande...@qt.io>> 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 > ${CMA

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: Fo

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 http://lists.qt-project.org/mailman/listinfo/de

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: cmake_mi

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: cmake_

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 w

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

On Sep 9, 2016, at 4:39 AM, Kevin Kofler mailto:kevin.kof...@chello.at>> wrote: 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

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. remo

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 inne

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 Ja

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 (thoug

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 i

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 wri

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 it > >>  canno

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 ar

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 bullet

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 another buildsystem? > > ... > > Why learn yet another programming language? > > ...

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, but beware: Qbs is addic

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 generator. :-) >> >>  This was done already

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 anyon

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: https:

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: https

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

On 06-Sep-16 19:59, André Pönitz wrote: On Tue, Sep 06, 2016 at 05:35:03PM +0200, 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

Cristian Adam wrote: > This was done already > , > but it was removed from CMake due to bad feedback from > Qt Creator people. Interesting, but why was that done on top of existing makefile generators? I'd expe

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

Jake Petroules wrote: > Again, useless, because Qbs is more powerful and at a much higher level of > abstraction, so a generator would only be useful in the reverse direction. Of course, the generator would not use all the features of Qbs, just the minimum subset that is needed to do the work. >

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

On Tue, Sep 06, 2016 at 05:35:03PM +0200, 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

Sent from my iPhone > On 06 Sep 2016, at 17:35, 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, but it was removed from CMake

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 , but it was removed from

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 use than m4, and also there is just one >> lay

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

On Sep 6, 2016, at 5:14 PM, Kevin Kofler mailto:kevin.kof...@chello.at>> 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 rather than having autoconf

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 i

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: d

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

On Sep 6, 2016, at 4:34 PM, Thiago Macieira mailto:thiago.macie...@intel.com>> wrote: Em terça-feira, 6 de setembro de 2016, às 16:29:38 PDT, Ulf Hermann escreveu: Do we have a policy about inappropriate content posted to mailing lists and similar communication channels? No, but there was a sid

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

Em terça-feira, 6 de setembro de 2016, às 16:29:38 PDT, Ulf Hermann escreveu: > Do we have a policy about inappropriate content posted to mailing lists and > similar communication channels? No, but there was a side-discussion at QCS that we should write and adopt a Code of Conduct. -- Thiago Ma

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 in

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 s

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

o Macieira 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, às 06:20:34 PDT, Thiago Macieira escreveu: > Building the host tools while cross-compiling is a

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 thin

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 knows about, says 10 to 20 prog

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 curiosity!

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 platform

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 in

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" : >> >> Andrew Knight wrote: >> >>> * Quick survey: which build syste

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 (raise of hands by ~40 > >>> people) > >>> -

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 ~10% >> >> That basically says it all. :-) Ye

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. I have switched quite a

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 complai

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 want

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 > mailto:kevin.kof...@chello.at>> 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 > project

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

On Sep 5, 2016, at 4:12 PM, Jake Petroules mailto:jake.petrou...@qt.io>> wrote: On Sep 5, 2016, at 3:38 PM, Kevin Kofler mailto:kevin.kof...@chello.at>> 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

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

On Sep 5, 2016, at 3:38 PM, Kevin Kofler mailto:kevin.kof...@chello.at>> 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, therefore X is great" is a poor

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 discussion of >>  which syst

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 int

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 write

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 no volunteers to do the work, many reasons to use

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 "obvious"

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 that there is volunteers to g

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 c