[Development] CMake branch

[Tobias Hunger]

Hi all,

On Thu, 2019-03-21 at 12:51 +0000, Volker Hilsheimer wrote:
> The advantages are:
>  - It allows our contributors to play with CMake in dev branch
>  - Speed-up the build of QtBase

How so?

>  - Easy to find a lot of bugs in CMake port
>  - CI could have a nightly build with CMake and generate a report

I am sure CI can be configured to do the same for any branch.

>  - We can synchronize CMakeFiles and *.pro files

I do not understand this part.

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

CI is a huge disadvantage! The last 3 patches I added to Qt took me 45 CI runs
to get in -- and I changed neither of these patches!


I see two more disadvantages:

First it requires that we can not do *anything* that will break qmake while
porting to CMake. 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.

Second will need to have CMake in a state where it will build qtbase at anytime
(or at least nearly so). So will need CMake to stay up-to-date with the qmake
build system at any time to keep things building. We have two options to achieve
this:

1) We can ask everybody to update CMake files whenever changing something in a
.pro/.pri file.

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.

2) We have a dedicated person that fixes CMake ASAP.

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

If we fail with updates too often, then we will poison the well: People are
enthusiastic about the cmake port (those that are not never get here), the build
fails, they are less enthusiastic. Repeat every couple of weeks until all
enthusiasm is gone. At that point it is hard to get people to try again. I had
that happen to me with qbs in Qt Creator.

> I’m fully supporting this proposal.

My idea was to ask for merging wip/cmake after 
https://bugreports.qt.io/browse/QTBUG-73925 (aka. "milestone 1"). At that point
the branch would be in a state where people can work on Qt (for certain
platforms) using cmake and do drive-by-contributions to cmake. Right now it is
more like working on CMake for Qt and doing drive-by-contributions to Qt:-)

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

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.


The wip/cmake branch is currently behind qt5/dev and we need to update it. So if
the Qt project decides to litter qtbase with CMakeLists.txt files ASAP, then we
will still need a while to send the actual patch for review.

Best Regards,
Tobias

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