[Interest] Qt 5.8.0 RC build under windows

Thiago Macieira thiago.macieira at intel.com
Sat Jan 21 17:24:14 CET 2017

On sábado, 21 de janeiro de 2017 13:00:28 PST Prav wrote:
> Hello, Thiago.
> > You do realise that those flags aren't supported and they may not compile,
> > right? I see commits going past every now and then fixing build failures
> > with those.
> Fixing commits goes to any part of Qt. I do not know what to tell. If some
> part of Qt have many bugs then it probably has not enough tests. Do you
> know if Qt have tests which checks if -no-feature-xxx flag breaks Qt build?

That's different. We have a Continuous Integration system that is supposed to 
keep any commits that break the Qt build or any unit test from ever reaching 
the repository. It's tested in many configurations. Then, at release time, we 
test everything again, and in many other configurations, to make sure it builds 
for people.

At no point in that process do we ever test any -no-feature-xxx flag.

There are some people who submit fixes for that when they find an issue. But the 
Qt Project does not test them or guarantee that they work.

> > The development mailing list is open to all and it has an archive. There's
> > absolutely nothing hidden.
> No. I am not about hiding. I am about subjectiveness. I never seen rules for
> naming something a feature in Qt.

If it's a new functionality that wasn't there before, it's a new feature.

> > Still, you avoided the question.
> No I do not. This is just my stylistics preference. I simply try to avoid to
> loose compatibility with older version of developer tools for nothing. Some
> times it plays bad role. This just from my experience. From experience I
> feels better keep compatibility if this is possible (at least reason of
> loosing compatibility should be exactly known). If this is some blur idea
> of "better behaviour" I vote for naming such update to be "feature" (which
> can be enabled/disabled for those who need it/avoid it).

Well, we disagree. Users of macOS are verry familiar with it: Qt requires the 
very latest Xcode to build and that uses the very latest SDK from Apple.

Requiring more from developers is not uncommon. Dropping compatibility with 
older compilers and older SDKs happens often, though for compilers we often 
make notice of it. This is the first time I can recall that an SDK has been an 

> > Why should we keep compatibility with older SDKs?
> I do not think that problems with developer tools versions bite
> linux-oriented developers much. 

Or for Apple platforms, since Apple updates very often.

> So have that in mind if you feels yourself
> closer to Linux world. For example now Qt can not be build with vc2010. But
> later vc-compilers can not be run on XP. So now I can not build Qt apps on
> XP. And I meet a lot of XP machines. Incompatible vc-compiler is not Qt's
> fault but MS. But as soon as MS has this tendency (push newer version of
> Windows with every possible way) ... even in developer tools ... I vote for
> not loosing compatibility with older version of developer tools. I do not
> know what tricky incompatibilities MS introduce in newer versions of
> WinSDK.

Qt Project is not a democracy and it has no votes. It's a meritocracy and 
technical arguments are accepted, discussed and either adopted or dismissed.

You can't build Qt on Windows XP because Qt doesn't run on Windows XP. So why 
would you build something whose native executables you can't launch or debug? 
We're not talking about cross-compilation here.

And, again, requiring something more from developers is not uncommon. We don't 
often do that for Windows, though.

> For example I do not understand : if c-compiler is simply a console app with
> 10's years history of development ... what so important it could need from
> WinVista so that it CAN NOT be run on older Windows?

It's a tiny functionality called "getting the time". It's required so that the 
event loop knows how much time has elapsed and so it can fire QTimer correctly.

Qt uses QueryPerformanceCounter and GetTickCount64, which are only guaranteed 
to be available in Vista. We used to use GetTickCount, but that has a problem 
that the counter overflows every 49.7 days, so if you kept your Windows machine 
running that long, applications would misbehave just because it was running, 
through no fault of your own.

So for Qt 5.7, I removed the old compatibility code that tried to detect at 
runtime whether you were on Windows Vista and above. Note that the 
compatibility check, even if a simple check-and-branch code, ran EVERY TIME 
the event loop tried to get the time. Which is about 1000 times per second...

> > So why should we disable that?
> I ask myself same question differently : why we lost compatibility?

Because we need some definitions from Windows headers so that we can call 
Windows 10 functions when the application detects it's running on Windows 10.

Anyway, since you turned the question around without answering it, I am 
reading the answer as "there's no good reason".

> >Someone added code to Qt that makes it behave better on Windows 10, without
> >dropping compatibility with Windows 7 and 8.1.
> We stick to your idea : "Someone added code to Qt that makes it behave
> better on Windows 10" But what exactly this is about. What "better"
> behavior for desktop Qt was added? I did not found anything about that in
> documentation ... and I can not find what become "better" from code.

I don't know either. I was not involved. You can read the log for the file in 
question to find out more.

> If we will find out eventually that nothing "better" was added to desktop Qt
> will you fix Win7SDK incompatibility?

I was not convinced there is a good reason for me to take action.

> PS
> It is also very suspicious for me that desktop app/lib needs to know
> something about WinRT part of Windows. And you OK with that?

I don't know where you got that from. All I saw was Windows 10, not WinRT.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Interest mailing list