[Development] MSVC 2019 pre-built binaries

[resurrection]

I was wondering what are the plans for the Qt pre-built binary release built with 
MSVC 2019 (16.0+)? The SP support for MSVC 2017 ends along with Window 7 support on 
14th January 2020 
(https://support.microsoft.com/en-us/lifecycle/search?alpha=Visual%20Studio%202017 
)
 and after that only the maintenance and no active development will be done for MSVC 
2017. It would make sense to switch to the 2019 even before that happens and favour 
it in the installer over the 2017 version. Or perhaps provide both for some time 
similar to how now there are both 2015 and 2017 versions now - having 2017+2019 and 
dropping 2015 whose support ends in 2020 anyway.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Who is in charge of qt-project.org?

[resurrection]

Here is what I replied to the mail (when sent to me only):
 
Hi,
This is absolutely true and we are well aware of this.
We had a bit similar issue earlier when we ramped down engin.io backend: 
https://blog.qt.io/blog/2016/01/26/notification-for-all-qt-cloud-services-users/
We try to avoid such things as much as possible, but sometimes we have to stop 
developing some item. Even when there are still users who depend upon it.
We also try to make it as smooth as we can – for example by keeping the 
deprecated feature usable for quite long time to allow enough time for 
transition.
Yours,
Tuukka

 
It seems to differ quite a bit in scale. That blog post has 7 comments. Compare it to nearly 150 on 
"Deprecation of Qbs" in 3 days and countless emails here on the mailing list. I seem to 
wonder if the whole issue could be avoided if it was approached a bit more diplomatically from the 
Qt Company's side. After all there is a point of you advertising the Qbs as the future before. The 
Qt Project has large community and maybe if you tried to hand it over to someone else in it things 
would not accrue nearly as much controversy. For example publically looking for a new maintainer 
with the goal to have it purely community driven in a year (and announce it as such). Rather than 
dropping the bomb-like title such as "Deprecation of Qbs".
 
It is a differnet situation to deprecating of an old technology (like Qt Quick 
Controls 1), isn't it? You are not doing it with Qbs on technical grounds but 
rather on business grounds so giving it the same treatment is just wrong in my 
opinion. Since your plan is to invest in it for a year anyway it would be 
better to spend that time (and money) on actively working to hand it over to 
someone. There have been people (and companies) in this very mailing list (and 
Qbs one) that said they would take it over. Announcing it to the world and 
waiting for the community to magically appear and contribute did not work 
during Qbs' life under the Qt Company (although after you invested in the docs 
its usage started to spike this year) so please do not make the same mistake 
again and give it a chance for real this time by _actively_ trying to hand it 
to someone else.
 
Michael

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[resurrection]

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

Re: [Development] Build system for Qt 6

[resurrection]

Honestly I feel very disappointed as well with this decision. I feel similarly 
to others, Qbs is now being phased out so fast (half a year of development, 
another half a year of maintanance after that it seems). So better get to 
porting stuff to CMake right away. Having experience with CMake this is gonna 
be very ugly... 
 
What I do not understand is why the decision was qmake + cmake in the first 
place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is 
perfectly understandable to tap into wide CMake user base but why ditching Qbs 
and not qmake? I wouldn't expect people would mourn qmake...
 
Oh and on the point of CMake. Lets write a simple if statement as per docs:
 
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. 
This will work:
 
string(COMPARE EQUAL ${var1} ${var2} _cmp)
if (_cmp)
    message("They are equal")
endif()
 
Yeah, fortunately there is a wide knowledge how to work around this kind of stuff. There 
are MANY other things like that that will make you cry when writing even simple things in 
CMake's "language". Not to mention CMake is not a build system, Qbs is.
 
Anyway, what's done is done I guess. 
Michael

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] clang-format

[resurrection]

Interesting discussion about using clang-format Qt wide. As someone who 
implemented something like that in a project (of smaller size than Qt, but not 
all that small) some points:
 
- clang-format virtually annihilates A LOT of manual work. It might not seem 
like much but I have measured it and even had to work on two projects 
simultaneously where only one had clang-format. It was staggering how much time 
is spent on formatting when done manually. And how much it annoys you since you 
KNOW it can be done for you, automatically and always correctly. It also speed 
things up because if you make a formatting mistake it will be corrected as soon 
as you save the file in Qt Creator. So you don't bother correcting it, you just 
go on typing or hit ctrl+s if it annoys you to see it. You will get seriously 
addicted to that. It is really quite liberating.
 
- I have read many concerns here about loss of immediate history, that 
clang-format does not get it always right etc. Well we had those too but one 
thing beats them all - free consistency. I could hardly believe it but even 
though I did not like all of the rules we put in it the fact that they were 
consistent everywhere made reading the code far easier than before. You could 
not be surprised, you knew where will everything be. Whether it was includes 
and their ordering (the epic battles about that in pre-clang-format era...), 
alignment, wrapping, you name it. Once you could rely on the fact that it will 
be the same everywhere you suddenly did not have to focus on formatting which 
(again surprisingly) took a lot of code review time for all parties.
 
- Continuous integration. I cannot stress this one enough. Make it a standard 
in the repo, make everyone enable it in Qt Creator, make a git hook and make it 
part of the build. Our CI failed when someone committed incorrectly formatted 
file telling him as much even before compilation or anything. It happened 
rarely as most people used the git hook but still.
 
- Most people will be sceptical until they start working with it. I guess this 
is a given for any new technology or approach. I know I was. But I am yet to 
come by a colleague that would complain about it or who would want to remove 
it. It might not be perfect but the benefits far outweigh any issues.
 
And on more practical note:
 
- We converted all sources at once and it has not caused any problems - it's 
just formatting anyhow.
- Some files (very few) turned out to be somewhat broken but the reason for that was that 
they were curiously formatted in the first place. We fixed those as they were 
encountered. It generated negligible amount of extra "work" (as mentioned 
hitting Enter for new line and saving file to reformat typically was the trick).
 
I became a huge fan of clang-format thanks to making my work a lot more 
pleasant and less tedious experience. It might not seem like much but it really 
makes a big difference in daily work. I really hope it will be adopted Qt-wide.
 
My 2 cents and I would gladly answer any questions about practicalities as 
someone who did pretty much all of it from converting all sources to 
implementing the git hook and CI stuff.
 
Best wishes,


Michael Vlach
Software Engineer
NCR

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development