[Development] Build system for Qt 6

NIkolai Marchenko enmarantispam at gmail.com
Tue Oct 30 09:45:15 CET 2018


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/45cff203/attachment.html>


More information about the Development mailing list