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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
