[Development] Build system for Qt 6
resurrection at centrum.cz
resurrection at centrum.cz
Tue Oct 30 09:21:02 CET 2018
//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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181030/0fd7a98b/attachment.html>
More information about the Development
mailing list