[Development] Build system for Qt 6

[Иван Комиссаров]

You have one year (or 2 Qt creator releases) to rewrite everything again=) 3, 2, 1, go!

Иван Комиссаров

> 30 окт. 2018 г., в 9:56, NIkolai Marchenko <enmarantispam at gmail.com> написал(а):
> 
> That's basically how I switched ppl here at my workplace to QBS: I've rewritten their .pro files for them and they didn't look back.
> 
>> On Tue, Oct 30, 2018 at 11:55 AM NIkolai Marchenko <enmarantispam at gmail.com> wrote:
>> And if you want large projects using it, shouldn't you have invested time and people actually helping those large projects rewrite their build system to QBS and show them just how good it is?
>> Any large project consists of a lot of experienced developers and every experienced developer knows that::"If i works, don't touch it".
>> 
>> Qt needed to invest time and resources to show at least a few projects the real benefit of qbs instead of hoping someone randomly would decide to rewrite what amounts of hundreds of ours in an extremely poorly documented system.
>> 
>>> On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko <enmarantispam at gmail.com> wrote:
>>> Main question is: why you even developing it, when you've never properly advertised/documented it? Just as an internal experiment?
>>> "Lets' make this thing and make sure almost no one knows of it or can find enough guidance to use it and then call it deprecated."
>>> 
>>> Like... this makes no sense whatsoever.
>>> 
>>> Part of it is me being annoyed at the loss of my primary build system ofc, but mostly I am generally baffled.
>>> 
>>>> On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko <enmarantispam at gmail.com> wrote:
>>>> I really have to wonder how can they think QBS is a failure when it was literally never given a chance.
>>>> 
>>>> Thiago, Lars : did you _really_ expect QBS to take off without any kind of proper documentation (has only started appearing in the last year) or advertisement? Seriously?
>>>> I've pointed out this artificial entry barrier for years. It's not that QBS hasn't taken off, the people who were responsible for it to take off did not do even minimal effort to make sure it did.
>>>> 
>>>> During the course of the last year QBS imporved in leaps in leaps and bounds and it suddenly comes to a schreeching halt now when it's really the time to push it to gain momentum....
>>>> 
>>>> I think you really need to revisit this topic before deprecating what could easily outclass CMAKE and the likes.
>>>> 
>>>> 
>>>> 
>>>>> On Tue, Oct 30, 2018 at 11:21 AM <resurrection at centrum.cz> wrote:
>>>>> //Christian Gagneraud wrote:
>>>>> //
>>>>> // // set(var1 "Hello")
>>>>> // // set(var2 "Hello")
>>>>> // // 
>>>>> // // if(var1 EQUAL var2)
>>>>> // //     message("They are equal")
>>>>> // // endif()
>>>>> // // 
>>>>> // // Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever.
>>>>> // 
>>>>> // You read the docs wrong:
>>>>> // EQUAL: True if the given string or variable’s value is a valid number and equal to that on the right.
>>>>> // Neither var1 nor var2 is a valid numbers.
>>>>> // 
>>>>> // You want
>>>>> // if (var1 STREQUAL var2) and this works as expected (and documented).
>>>>> // 
>>>>> // //
>>>>> // Christian
>>>>>  
>>>>> No it does not. Have you tried it? As I mentioned it does not work. And even if you somehow managed to make it work it would break the moment someone would define the variable "Hello" elsewhere in the script. See https://cmake.org/pipermail/cmake/2013-February/053587.html
>>>>>  
>>>>> And that is the point. The fact we are discussing the very fundamental programming feature - control flow - that just does not work as expected (or documented) is the main problem with CMake. It is a software made of features botched together. You will be constantly running into these kinds of things because it is CMake "language" is not a standardized programming language (like JS is). Writing complex projects in it is extremely difficult which I have been unfortunate to experience first hand (had to write a few in it). While the business decision might be understandable from the technical standpoint it is an absolute nightmarish prospect. Not to mention it is very slow so working with codebase the size of Qt will be extra difficult. There will likely be effort to improve on that either on CMake side (if they cared) or QtComany side (more likely, because they do care).
>>>>>  
>>>>> However I have no problem with CMake becoming the primary build generator replacing qmake. It is widespread etc. My issue is with deprecating Qbs. Having 2 people (likely very motivated now after they spent years developing Qbs) transfered or replaced to CMake support in Qt can hardly mean "Deprecating Qbs allows us to significantly improve CMake support.". Sounds more like standard PR BS to me, sorry.
>>>>>  
>>>>> And saying Qbs got a chance when it was literally never promoted anywhere, not even in Qt project itself is riduclous. And coming from Thiago who even claimed before he never actually used it.
>>>>> _______________________________________________
>>>>> Development mailing list
>>>>> Development at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181030/23d283fb/attachment.html>