You have one year (or 2 Qt creator releases) to rewrite everything again=) 3,
2, 1, go!
Иван Комиссаров
> 30 окт. 2018 г., в 9:56, NIkolai Marchenko <enmarantis...@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 <enmarantis...@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
>>> <enmarantis...@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
>>>> <enmarantis...@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 <resurrect...@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@qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
