[Development] CMake branch

[Mikhail Svetkin]

> How so

They can use ninja.

> I do not understand this part.

 We can ask people to update CMakeFiles after updating pro files.

> First it requires that we can not do *anything* that will break qmake while
porting to CMake.

Why do we need to break qmake?

> So no moving of files, no removal of files, no renaming, no
fixes to the source code, nothing. Considering that we generate most CMake files
straight from the .pro-files, that is probably not too much of a problem, but it
does take options of the table.

If you want to move files you can update pro files and qmake build. The same for another operations.

> I do not think we should ask people to handle this extra annoyance for years to
come -- till the last Qt 5 LTS will go out of scope.

We do not have so many changes inside pro files and we need to do it anyway. Also it will help people to be more familiar with CMake.

> We need volunteers for this! I do not see the team currently trying to port
Qtbase to CMake having the necessary resources.

I think people do not want to just play with CMake. They want to build Qt (in our case QtBase) with CMake and if they encounter issues some people more likely to fix the issues.
So I think It can help us to involve them.

> We have no decision from the Qt project yet. Submitting a patch for review and
getting that accepted would be such a decision:-) For this reason alone I would
very much welcome this proposal -- *if* we get volunteers to help with keeping
cmake up-to-date with qmake.

Let's send a patch and see what happens.

Best regards,
Mikhail
________________________________
From: Mikhail Svetkin
Sent: Thursday, March 21, 2019 4:06 PM
To: Alex Blasche
Cc: development at qt-project.org
Subject: Re: [Development] CMake branch

> I find it hard to believe that this improves the quality of Qt 5.14 or 5.15. Effectively you are proposing that we don't have any blocking CI for those two Qt releases. Otherwise you would have to implement very intrinsic rules when to block and when not to block. Even seemingly innocent/unrelated doc changes have been known to break Qt builds.

I think maybe it is some kind of misunderstanding here.
The CI will be enable. It will not test CMake.
Even CMake won't be tested it will still need to go through the CI.


Best regards,
Mikhail
________________________________
From: Volker Hilsheimer
Sent: Thursday, March 21, 2019 1:51 PM
To: Mikhail Svetkin
Cc: development at qt-project.org
Subject: Re: [Development] CMake branch

On 21 Mar 2019, at 13:00, Mikhail Svetkin <Mikhail.Svetkin at qt.io<mailto:Mikhail.Svetkin at qt.io>> wrote:


Hi everyone!

We’ve had an internal discussion about wip/cmake branch.

We thought maybe it is a good idea to merge wip/cmake into dev branch.

The advantages are:
 - It allows our contributors to play with CMake in dev branch
 - Speed-up the build of QtBase
 - Easy to find a lot of bugs in CMake port
 - CI could have a nightly build with CMake and generate a report
 - We can synchronize CMakeFiles and *.pro files

The disadvantages are:
 - Any changes should be passed by CI

Do you have any objections?


I’m fully supporting this proposal.


By doing the cmake work in a separate branch, we are keeping this hidden from everyone else. That was the right thing to do while we didn’t know if we want to go with it and what the structural implications of this change will be, but now we know, and it’s time to move this work into the mainline.

Having this in a branch prevents people that can help out from doing so effectively, and generally introduces a lot of waste.


Of course, more changes hitting dev means more CI runs, and there’ll likely be some unsupported cmake files in the next releases made off of dev, but that doesn't do any harm.


Volker


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190321/f03d9dba/attachment.html>