Re: [Development] Future of QBS

On 18/10/17 21:35, Kevin Funk wrote: On Monday, 16 October 2017 22:48:06 CEST Christian Gagneraud wrote: I think my questioning was legit, even if the style was far from perfect. Right, let me excuse myself as well for the strong wording. Hi Kevin, "Sweet as" as they say here in New

Re: [Development] Future of QBS

> On 18. Oct 2017, at 08:46, Jeandet Alexis > wrote: > > Le mardi 17 octobre 2017 à 17:45 +0200, Giuseppe D'Angelo a écrit : >> I'm just going to ignore the bikeshedding on implementation details, and >> go back to the main point of the thread, which was right

Re: [Development] Future of QBS

On Wed, 18 Oct 2017 08:46:34 +0200 Jeandet Alexis wrote: > Le mardi 17 octobre 2017 à 17:45 +0200, Giuseppe D'Angelo a écrit : > > (Small story: when I presented Qt Creator at CppCon last year, > > people's > > reactions were always these two: > > > > 1) "Oh,

Re: [Development] Future of QBS

On Monday, 16 October 2017 22:48:06 CEST Christian Gagneraud wrote: > On 16 October 2017 at 21:40, Kevin Funk wrote: > > On Sunday, 15 October 2017 11:20:13 CEST Christian Gagneraud wrote: > >> On 14 October 2017 at 04:22, Jean-Michaël Celerier > >> > >>

Re: [Development] Future of QBS

On 10/17/2017 05:04 PM, Lisandro Damián Nicanor Pérez Meyer wrote: I would need to be sure it bootstraps itself (ie, it doesn't needs Qt in order to build qbs) to accept it. Else it would be a nightmare to maintain. Much like qmake actually does if I understand correctly. We're aware of this

Re: [Development] Future of QBS

Le mardi 17 octobre 2017 à 17:45 +0200, Giuseppe D'Angelo a écrit : > I'm just going to ignore the bikeshedding on implementation details, > and > go back to the main point of the thread, which was right here: > > Il 13/10/2017 16:56, Sergio Martins ha scritto: > > Please make something we can

Re: [Development] Future of QBS

On Wed, Oct 18, 2017 at 06:35:39AM +, Jake Petroules wrote: > On Oct 18, 2017, at 12:48 AM, Christian Gagneraud wrote: > > The leak: > > Current Qt build system (qmake) leaks into Qbs via qbs-setup-qt. > qtc and qbs-setup-qt use qmake, because that's the authoritative source

Re: [Development] Future of QBS

> On 18. Oct 2017, at 08:35, Jake Petroules wrote: > > > >> On Oct 18, 2017, at 12:48 AM, Christian Gagneraud wrote: >> >> The trap: >> From reading your comments, I had the feeling that you're thinking that >> building Qt with Qbs will help having a

Re: [Development] Future of QBS

> On Oct 18, 2017, at 12:48 AM, Christian Gagneraud wrote: > > The trap: > From reading your comments, I had the feeling that you're thinking that > building Qt with Qbs will help having a better Qt/Qbs integration when > building the user's project. > I think it's

Re: [Development] Future of QBS

On 17/10/2017 11:27 PM, Jake Petroules wrote: We both want to solve the same problems, but I'm not sure exactly what you mean here about how building Qt with Qbs is a trap and that we should not "leak". The trap: From reading your comments, I had the feeling that you're thinking that building

Re: [Development] Future of QBS

A few points: * Unless you are worried about building software with possibly infinite dependencies, infinite build products, then a non-Turing complete language that just lacks general recursion will be sufficiently expressive to meet your needs. In particular, this means those vaguely

Re: [Development] Future of QBS

Op 17/10/2017 om 17:31 schreef Oswald Buddenhagen: > On Tue, Oct 17, 2017 at 05:23:17PM +0200, Ulf Hermann wrote: Exactly. The halting problem can be worked around pragmatically. >>> ... at the price of getting different build results based on CPU speed ... >>> >>> Your fast desktop CPU

Re: [Development] Future of QBS

I'm just going to ignore the bikeshedding on implementation details, and go back to the main point of the thread, which was right here: Il 13/10/2017 16:56, Sergio Martins ha scritto: Please make something we can easily detach from the qt-project in 10 years and have it's own ecosystem. The

Re: [Development] Future of QBS

On Tue, Oct 17, 2017 at 05:23:17PM +0200, Ulf Hermann wrote: > >> Exactly. The halting problem can be worked around pragmatically. > > > > ... at the price of getting different build results based on CPU speed ... > > > > Your fast desktop CPU crunches through the JS and you get a working > >

Re: [Development] Future of QBS

On Tue, 17 Oct 2017 17:23:17 +0200 Ulf Hermann wrote: > >> Exactly. The halting problem can be worked around pragmatically. > > > > ... at the price of getting different build results based on CPU speed ... > > > > Your fast desktop CPU crunches through the JS and you get

Re: [Development] Future of QBS

>> Exactly. The halting problem can be worked around pragmatically. > > ... at the price of getting different build results based on CPU speed ... > > Your fast desktop CPU crunches through the JS and you get a working > built, while my sucky laptop CPU does not and the build fails for me. A

Re: [Development] Future of QBS

On Tue, Oct 17, 2017 at 9:34 AM, Joerg Bornemann wrote: > On 10/17/2017 08:12 AM, André Somers wrote: > >> Well, in the case of QBS, would it not be reasonable to terminate the >> evaluation of any property binding if it takes more than a >> amount of time? The language

Re: [Development] Future of QBS

On domingo, 15 de octubre de 2017 10:23:57 -03 Jake Petroules wrote: [snip] > > We've already decided internally that we want to push Qbs as the new build > tool, and I have no doubt that the community will agree. I would need to be sure it bootstraps itself (ie, it doesn't needs Qt in order

Re: [Development] Future of QBS

On 2017-10-17 05:49, Konstantin Tokarev wrote: > 17.10.2017, 05:06, "Kevin Kofler" wrote: >> Konstantin Tokarev wrote: >>>  * It is target-oriented from the start and is not so burdened by legacy >>>  ways of doing things wrong, which plague old CMake projects and confuse >>>  newcomers >> >>

Re: [Development] Future of QBS

17.10.2017, 17:26, "Matthew Woehlke" : > On 2017-10-16 22:05, Kevin Kofler wrote: >>  Konstantin Tokarev wrote: >>>  I have no real experience with Meson, but at least it has following >>>  advantages: >>> >>>  * Its language is typed(!), >> >>  CMake also has a concept

Re: [Development] Future of QBS

On 2017-10-16 22:05, Kevin Kofler wrote: > Konstantin Tokarev wrote: >> I have no real experience with Meson, but at least it has following >> advantages: >> >> * Its language is typed(!), > > CMake also has a concept of types. In particular, the cache variables (i.e., > the variables you can set

Re: [Development] Future of QBS

> On Oct 17, 2017, at 12:17 PM, Christian Gagneraud wrote: > > With all due respect may I suggest that building qt with qbs is actually a > trap, please don't rely on that to solve your user's problems. > Qt is your toolkit, not mine. You should not leak. (No offense. I'm

Re: [Development] Future of QBS

On 17/10/2017 9:30 pm, "Jake Petroules" wrote: > On Oct 17, 2017, at 9:21 AM, Christian Gagneraud wrote: > > On 17/10/2017 7:52 pm, "Jake Petroules" wrote: > > > On Oct 16, 2017, at 3:34 PM, jeandet

Re: [Development] Future of QBS

17.10.2017, 12:49, "Konstantin Tokarev" : > 17.10.2017, 05:06, "Kevin Kofler" : >>>   * Its language has native support for properties, with syntax that really >>>   looks like properties in another languages >> >>  That is what the GET_*_PROPERTY and

Re: [Development] Future of QBS

17.10.2017, 05:20, "Kevin Kofler" : > PS: Oh, and I forgot: > > Konstantin Tokarev wrote: >>  [Meson] is written in scripting language > > In addition to what I already wrote, this also implies that the scripting > language (Python in this case) interpreter is required to

Re: [Development] Future of QBS

17.10.2017, 04:01, "Kevin Kofler" : > Konstantin Tokarev wrote: >>  This problem is solved by having access to full "project" model from the >>  same language. E.g. this is how I implemented Premake plugin for Qt >>  Creator a while ago: added Lua code to traverse

Re: [Development] Future of QBS

17.10.2017, 05:06, "Kevin Kofler" : > Konstantin Tokarev wrote: >>  I have no real experience with Meson, but at least it has following >>  advantages: >> >>  * Its language is typed(!), > > CMake also has a concept of types. In particular, the cache variables (i.e., >

Re: [Development] Future of QBS

> On Oct 17, 2017, at 9:21 AM, Christian Gagneraud wrote: > > On 17/10/2017 7:52 pm, "Jake Petroules" wrote: > > > On Oct 16, 2017, at 3:34 PM, jeandet wrote: > > > > I have the feeling that a Qt build system will always

Re: [Development] Future of QBS

On 10/17/2017 08:12 AM, André Somers wrote: Well, in the case of QBS, would it not be reasonable to terminate the evaluation of any property binding if it takes more than a amount of time? The language may be Turing-complete, but that does not mean the code in control of executing it has to

Re: [Development] Future of QBS

On 17/10/2017 7:52 pm, "Jake Petroules" wrote: > On Oct 16, 2017, at 3:34 PM, jeandet wrote: > > I have the feeling that a Qt build system will always force the users > to choose between another tool they know but where the Qt support might

Re: [Development] Future of QBS

> On Oct 16, 2017, at 3:34 PM, jeandet wrote: > > I have the feeling that a Qt build system will always force the users > to choose between another tool they know but where the Qt support might > not be the best and a Qt focused tool with a good Qt support but

Re: [Development] Future of QBS

Op 17/10/2017 om 03:01 schreef Kevin Kofler: > Konstantin Tokarev wrote: >> This problem is solved by having access to full "project" model from the >> same language. E.g. this is how I implemented Premake plugin for Qt >> Creator a while ago: added Lua code to traverse Premake's project >>

Re: [Development] Future of QBS

PS: Oh, and I forgot: Konstantin Tokarev wrote: > [Meson] is written in scripting language In addition to what I already wrote, this also implies that the scripting language (Python in this case) interpreter is required to build anything with it, whereas a build system in C++ such as CMake

Re: [Development] Future of QBS

Konstantin Tokarev wrote: > I have no real experience with Meson, but at least it has following > advantages: > > * Its language is typed(!), CMake also has a concept of types. In particular, the cache variables (i.e., the variables you can set on the command line, which are also cached across

Re: [Development] Future of QBS

On 16 October 2017 at 21:40, Kevin Funk wrote: > On Sunday, 15 October 2017 11:20:13 CEST Christian Gagneraud wrote: >> On 14 October 2017 at 04:22, Jean-Michaël Celerier >> >> wrote: >> >> nobody is going to port Qt to CMake (if you disagree

Re: [Development] Future of QBS

16.10.2017, 19:02, "jeandet" : > Le lundi 16 octobre 2017 à 15:46 +0300, Konstantin Tokarev a écrit : >>  That said, I totally dislike the idea of inventing restricted DSL >>  language for build system >>  instead of using general purpose language (like e.g. in QBS

Re: [Development] Future of QBS

Hello, My two cents as a Qt user and occasional Meson contributor. I have the feeling that a Qt build system will always force the users to choose between another tool they know but where the Qt support might not be the best and a Qt focused tool with a good Qt support but they will have to deal

Re: [Development] Future of QBS

Hi Jake, take a breath, I was not even trying to attack qbs. These debates get way too emotional for my taste! All I did was to ask to see qbs *sold* better and with more facts backing up our claims about it. > > to use your version control picture: Are we trying to sell > > subversion by

Re: [Development] Future of QBS

Prolog is turing-complete and hence can be used to construct programs which do not terminate. On 10/16/2017 09:42 AM, Konstantin Tokarev wrote: 16.10.2017, 16:17, "Adam Treat" : You'll need a strongly normalizing language for that which does not allow general recursion.

Re: [Development] Future of QBS

16.10.2017, 16:17, "Adam Treat" : > You'll need a strongly normalizing language for that which does not > allow general recursion. Something built on the simply typed lambda > calculus, but with added syntactic sugar would do. Maybe Prolog would do it too. >> >>  Ulf >>  

Re: [Development] Future of QBS

16.10.2017, 16:08, "Ulf Hermann" : >>  I have no real experience with Meson, but at least it has following >> advantages: >> >>  * Its language is typed(!), has native support for arrays(!), and >> functions/methods have >>  first-class return values(!) >>  * Its language

Re: [Development] Future of QBS

On 10/16/2017 03:16 PM, Adam Treat wrote: > You'll need a strongly normalizing language for that which does not allow > general recursion. Something built on the simply typed lambda calculus, but > with added syntactic sugar would do. Hmm, is it possible to define a subset of JavaScript with

Re: [Development] Future of QBS

> On Oct 16, 2017, at 2:46 PM, Konstantin Tokarev wrote: > > I have no real experience with Meson, but at least it has following > advantages: > > * Its language is typed(!), has native support for arrays(!), and > functions/methods have > first-class return values(!) > *

Re: [Development] Future of QBS

You'll need a strongly normalizing language for that which does not allow general recursion. Something built on the simply typed lambda calculus, but with added syntactic sugar would do. On 10/16/2017 09:08 AM, Ulf Hermann wrote: I have no real experience with Meson, but at least it has

Re: [Development] Future of QBS

> I have no real experience with Meson, but at least it has following > advantages: > > * Its language is typed(!), has native support for arrays(!), and > functions/methods have > first-class return values(!) > * Its language has native support for properties, with syntax that really > looks

Re: [Development] Future of QBS

16.10.2017, 15:06, "Kevin Kofler" : > Tobias Hunger wrote: >>  I am still missing a comparison of qbs and *current* build system options. >>  All I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake >>  is what qbs will be competing with by the time it is

Re: [Development] Future of QBS

> Meson is, as far as I can tell (I had already looked at it a couple times), > mostly a CMake clone written in Python. I fail to see how it is conceptually > any different from (let alone better than) CMake. It is mainly pushed by > GNOME developers who are fed up of stone-age autotools, but

Re: [Development] Future of QBS

Tobias Hunger wrote: > I am still missing a comparison of qbs and *current* build system options. > All I see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake > is what qbs will be competing with by the time it is ready to be used in > earnest. > > So far we excluded most possible

Re: [Development] Future of QBS

16.10.2017, 13:59, "Konstantin Tokarev" : > 15.10.2017, 12:20, "Christian Gagneraud" : >>  On 14 October 2017 at 04:22, Jean-Michaël Celerier >>   wrote:   nobody is going to port Qt to CMake (if you disagree start a new

Re: [Development] Future of QBS

15.10.2017, 12:20, "Christian Gagneraud" : > On 14 October 2017 at 04:22, Jean-Michaël Celerier > wrote: >>>  nobody is going to port Qt to CMake (if you disagree start a new thread) >> >>  https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8 >

Re: [Development] Future of QBS

> On Oct 16, 2017, at 11:14 AM, Tobias Hunger wrote: > > Hi Jake, > > to use your version control picture: Are we trying to sell subversion by > showing how great that is compared to CVS and RCS, while git is just getting > introduced into the market? Your analogy is

Re: [Development] Future of QBS

16.10.2017, 10:31, "Jake Petroules" : >>  On Oct 16, 2017, at 4:42 AM, Kevin Kofler wrote: >> >>  Christian Gagneraud wrote: >>>  I would resume this post as "I love CMake, CMake is the only way. >>>  You're all wrong." >>>  This post doesn't

Re: [Development] Future of QBS

> We've been investing into qbs since a while, and have been open about our > plans for building Qt itself with it. Even if there is no official decision > by the Qt Project to switch yet (and I think this can only be done once we > have a full port working), I think it's only fair for the

Re: [Development] Future of QBS

16.10.2017, 05:43, "Kevin Kofler" : > Christian Gagneraud wrote: >>  I would resume this post as "I love CMake, CMake is the only way. >>  You're all wrong." >>  This post doesn't explain anything, doesn't gives any analysis, no >>  comparison, no argument whatsoever,

Re: [Development] Future of QBS

> -Original Message- > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt- > Subject: Re: [Development] Future of QBS > > Hi Jake, > > to use your version control picture: Are we trying to sell subversion by > showing how great that is compared t

Re: [Development] Future of QBS

Hi Jake, to use your version control picture: Are we trying to sell subversion by showing how great that is compared to CVS and RCS, while git is just getting introduced into the market? I am still missing a comparison of qbs and *current* build system options. All I see is qbs vs. qmake and

Re: [Development] Future of QBS

On Mon, 16 Oct 2017 01:23:51 +0800 Ben Lau wrote: > I am still new to QBS, but I think it is better than CMake too. However, I > think it has missed a critical feature - A simple way to run custom script. > > For example, run a script to call external command (not a product

Re: [Development] Future of QBS

On Sunday, 15 October 2017 11:20:13 CEST Christian Gagneraud wrote: > On 14 October 2017 at 04:22, Jean-Michaël Celerier > > wrote: > >> nobody is going to port Qt to CMake (if you disagree start a new thread) > > > >

Re: [Development] Future of QBS

> On Oct 16, 2017, at 4:42 AM, Kevin Kofler wrote: > > Christian Gagneraud wrote: >> I would resume this post as "I love CMake, CMake is the only way. >> You're all wrong." >> This post doesn't explain anything, doesn't gives any analysis, no >> comparison, no argument

Re: [Development] Future of QBS

On 16/10/2017 7:31 pm, "BogDan Vatra" wrote: On luni, 16 octombrie 2017 17:38:53 EEST Christian Gagneraud wrote: > On 16 October 2017 at 15:42, Kevin Kofler wrote: > > Christian Gagneraud wrote: > >> I would resume this post as "I love CMake, CMake is

Re: [Development] Future of QBS

On luni, 16 octombrie 2017 17:38:53 EEST Christian Gagneraud wrote: > On 16 October 2017 at 15:42, Kevin Kofler wrote: > > Christian Gagneraud wrote: > >> I would resume this post as "I love CMake, CMake is the only way. > >> You're all wrong." > >> This post doesn't

Re: [Development] Future of QBS

On 16 October 2017 at 15:42, Kevin Kofler wrote: > Christian Gagneraud wrote: >> I would resume this post as "I love CMake, CMake is the only way. >> You're all wrong." >> This post doesn't explain anything, doesn't gives any analysis, no >> comparison, no argument

Re: [Development] Future of QBS

Christian Gagneraud wrote: > I would resume this post as "I love CMake, CMake is the only way. > You're all wrong." > This post doesn't explain anything, doesn't gives any analysis, no > comparison, no argument whatsoever, nothing. It makes one important point (and elaborates it to great

Re: [Development] Future of QBS

On Sunday, 15 October 2017 02:20:13 PDT Christian Gagneraud wrote: > How many people had the same reaction when clang started? > Nowadays, clang is actually far superior to gcc, it brought tooling > like we would never have dared to dream of . Clang may be far superior to GCC in a lot of aspects.

Re: [Development] Future of QBS

On Sunday, 15 October 2017 03:23:57 PDT Jake Petroules wrote: > We've already decided internally that we want to push Qbs as the new build > tool, and I have no doubt that the community will agree. I have no doubt the community agrees that you have the right to try. Whether the community agrees

Re: [Development] Future of QBS

> On Oct 15, 2017, at 7:23 PM, Ben Lau wrote: > > > On 14 October 2017 at 00:55, Denis Shienkov wrote: > Hi all, my 5-cents: > > QBS is better (best best) than CMake, IMHO, as CMake is too complicated. :) > > > I am still new to QBS, but I

Re: [Development] Future of QBS

On 14 October 2017 at 00:55, Denis Shienkov wrote: > Hi all, my 5-cents: > > QBS is better (best best) than CMake, IMHO, as CMake is too complicated. > :) > > I am still new to QBS, but I think it is better than CMake too. However, I think it has missed a critical

Re: [Development] Future of QBS

On 15 October 2017 at 23:23, Jake Petroules wrote: > > >> On Oct 15, 2017, at 11:20 AM, Christian Gagneraud wrote: >> >> On 14 October 2017 at 04:22, Jean-Michaël Celerier >> wrote: nobody is going to port Qt to CMake

Re: [Development] Future of QBS

> On Oct 15, 2017, at 11:20 AM, Christian Gagneraud wrote: > > On 14 October 2017 at 04:22, Jean-Michaël Celerier > wrote: >>> nobody is going to port Qt to CMake (if you disagree start a new thread) >> >>

Re: [Development] Future of QBS

On 14 October 2017 at 04:22, Jean-Michaël Celerier wrote: >> nobody is going to port Qt to CMake (if you disagree start a new thread) > > https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8 I would resume this post as "I love CMake, CMake is the only way. You're

Re: [Development] Future of QBS

Hi all, my 5-cents: QBS is better (best best) than CMake, IMHO, as CMake is too complicated. :) QBS needs still in BinaryFiles support (e.g. to allow todo patching, merge for some output files using custom algorithms), better QtC integration (e.g. with Android && iOS). In other things QBS is

Re: [Development] Future of QBS

On Fri, Oct 13, 2017 at 04:19:51PM +0100, Sergio Martins wrote: > On 2017-10-13 16:12, Thiago Macieira wrote: > > On Friday, 13 October 2017 07:56:47 PDT Sergio Martins wrote: > >> IMHO the qt-project is not in a position to reject Qt building with > >> qbs, simply because there's no other

Re: [Development] Future of QBS

> nobody is going to port Qt to CMake (if you disagree start a new thread) https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8 > a complete CMake build for Qt was already contributed upstream (quite some time ago) .. and rejected .. --- Jean-Michaël Celerier http://www.jcelerier.name

Re: [Development] Future of QBS

On Friday, 13 October 2017 07:56:47 PDT Sergio Martins wrote: > IMHO the qt-project is not in a position to reject Qt building with qbs, > simply because there's no other implementation, nobody is going to port > Qt to CMake (if you disagree start a new thread). There are volunteers to do that.

[Development] Future of QBS

Hi, At the QtCS it was mentioned that maybe qbs could use JavaScriptCore and std:: types, at first I thought this was for making it easy for qbs to be a non-Qt project, but then I realized it was for boot-strapping purposes. I don't know if you have a vision, but given that most other build