[Development] Build system for Qt 6

[NIkolai Marchenko]

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
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181030/ccd91449/attachment.html>