//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
