[Development] CMake branch

Tobias Hunger Tobias.Hunger at qt.io
Fri Mar 22 13:00:29 CET 2019

Am Freitag, den 22.03.2019, 10:45 +0000 schrieb Jedrzej Nowacki:
>   I'm supporting Mikhail' proposal and I'm probably a bit guilty of the
> thread 
> too. As some of you know I'm not enthusiastic about any build system. I
> really 
> think that there are too complex for the purpose. What I care about is 
> shortening my development cycle and I can see how the cycle could be reduced 
> with ninja. I could try to help with porting to cmake, but I have nothing to 
> do in the wip branch. At the point in which cmake port works in at least on 
> one platfrom with developer build I do not see reason to not have it in 
> dev(*). 

So you are one of the people I referred to as wanting to work on Qt using cmake.
IMHO we can not support you at this time. 

>   I'm also a bit afraid that we are making the same delivery mistake as with 
> qbs.

We do the same mistake as we did with Qbs: We have way too few people working on
it to make it in time.

>  Everything is hidden behind an outdated feature branch. It requires quite 
> a mental effort to actually look there. By looking there you need to be 
> determined on working on the feature (there is nothing else there). 

Yes, that is the state we are in: You need to want to work on cmake to find the
branch interesting.

>   In addition seems that we go with a big bang approach, which worries me a 
> bit. Could you explain me why the temporary goal is to have two parallel
> build 
> systems?

Mostly to be able to compare results from qmake and cmake. It is pretty
convenient at this time.

>  Why we can not port stuff one by one and allow qmake to call cmake and 
> cmake to call qmake? For example why we can not already (*) require cmake to 
> build tests, moc, plugins and others?

*sigh* The task is hard enough already, please do not complicate it by requiring
qmake and cmake to seamlessly interact with each other at arbitrary points in
the build process.

>   There was also argument that we should not have cmake stuff in qt5 LTS. I
> do 
> not understand it, to be honest. That is really an implementation detail of 
> Qt.

A build system is *NOT* an implementation detail that is invisible to anybody
but developers of Qt.

Switching build systems does introduce a real risk to break a certain compilers,
setups and use-cases for all users and customers of Qt 5. We will also
definitely breaking each and every packaging script for Qt 5 out there in
existing. We break each and every instruction on how to build Qt 5 that was ever
published. We will also break all a lot of instructions on how to build against
Qt (probably even those that are concerned with cmake:-).

We should IMHO not expose our users and customers to such a risk in a minor
release. The only option to switch to an *exclusive* CMake based build system
that we have is IMHO Qt 6 (or Qt 7 if we miss that one).

But from what I understand this is not the proposal we are talking about. This
is about introducing cmake as a *secondary build system for Qt 5*, in
preparation for making it exclusive in Qt 6. I am fine with that.

As a secondary build systems our hands are much more tied with the cmake port
with regards to deviating from what qmake did than before.

I am also not at all enthusiastic about having to push all my CMake changes
through CI. That will eat a lot of extra time! I really do not understand how
you Qt developers can work like that...

>  We can have some transition scripts so configure && make && make install 
> somehow workflow works, but that is all.

Transition scripts work great, except when they don't:-/

qmake and cmake do moc differently, they handle .ui files differently. They
handle shared code much differently. There are lots of subtle differences all
over the place. Some will bite users, even when you try to hide all of that
behind transition scripts.

> (*) With assumption that we agree that cmake is the chosen one. I do not
> think 
> that the port needs to be ready before accepting it. In my opinion it is 
> enough to commit to it based on the state of the wip/cmake branch.

Please try to fix a bug in Qt with the wip/cmake branch and tell me how that
worked out for you. I doubt that you will enjoy that experience at this time.

>  So are we 
> sure that cmake is the way to go?

I think it is the only option we have right now.

>  If yes then let's go to dev.

... once we updated the wip/cmake branch to qt5/dev. Currently it is way behind.
Any help in getting that done is greatly appreciated.

Best Regards,

Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

More information about the Development mailing list