[Development] CMake branch
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? Best regards, Mikhail ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On 21.3.2019 14.00, Mikhail Svetkin 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? > > ** > Would this have blocking CI or not? The stated disadvantage (which surely shouldn't be entirely negative) implies that it would be. But the build being nightly hints that it would not be. A blocking build would mean that all changes need to leave the CMake build working. So everyone would need to take care of both build systems. A more defined transition point and only one official build system at a time would be nicer. Or at least trying to minimize the time of having two. Unless of course we'd already be ready to drop building Qt with qmake, but I guess that's not where we are yet. Is that expected to happen during 5.x series at all or only with Qt 6? -- Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
It should not be blocking for Qt 5. We can generate a non-blocking integration report. Best regards, Jesús From: Development on behalf of Kari Oikarinen Sent: 21 March 2019 13:13 To: Mikhail Svetkin; development@qt-project.org Subject: Re: [Development] CMake branch On 21.3.2019 14.00, Mikhail Svetkin 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? > > ** > Would this have blocking CI or not? The stated disadvantage (which surely shouldn't be entirely negative) implies that it would be. But the build being nightly hints that it would not be. A blocking build would mean that all changes need to leave the CMake build working. So everyone would need to take care of both build systems. A more defined transition point and only one official build system at a time would be nicer. Or at least trying to minimize the time of having two. Unless of course we'd already be ready to drop building Qt with qmake, but I guess that's not where we are yet. Is that expected to happen during 5.x series at all or only with Qt 6? -- Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
It will not block CI. Best regards, Mikhail From: Kari Oikarinen Sent: Thursday, March 21, 2019 1:13 PM To: Mikhail Svetkin; development@qt-project.org Subject: Re: [Development] CMake branch On 21.3.2019 14.00, Mikhail Svetkin 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? > > ** > Would this have blocking CI or not? The stated disadvantage (which surely shouldn't be entirely negative) implies that it would be. But the build being nightly hints that it would not be. A blocking build would mean that all changes need to leave the CMake build working. So everyone would need to take care of both build systems. A more defined transition point and only one official build system at a time would be nicer. Or at least trying to minimize the time of having two. Unless of course we'd already be ready to drop building Qt with qmake, but I guess that's not where we are yet. Is that expected to happen during 5.x series at all or only with Qt 6? -- Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Could you explain the stated disadvantage further then? -- Kari On 21.3.2019 14.21, Mikhail Svetkin wrote: > It will not block CI. > > > > > Best regards, > Mikhail > > *From:* Kari Oikarinen > *Sent:* Thursday, March 21, 2019 1:13 PM > *To:* Mikhail Svetkin; development@qt-project.org > *Subject:* Re: [Development] CMake branch > > > On 21.3.2019 14.00, Mikhail Svetkin 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? >> >> ** >> > > Would this have blocking CI or not? The stated disadvantage (which surely > shouldn't be entirely negative) implies that it would be. But the build being > nightly hints that it would not be. > > A blocking build would mean that all changes need to leave the CMake build > working. So everyone would need to take care of both build systems. A more > defined transition point and only one official build system at a time would be > nicer. Or at least trying to minimize the time of having two. > > Unless of course we'd already be ready to drop building Qt with qmake, but I > guess that's not where we are yet. Is that expected to happen during 5.x > series > at all or only with Qt 6? > > -- > Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Never mind. The issue is of course that changes need to go through CI, even though it doesn't check them. -- Kari On 21.3.2019 14.21, Mikhail Svetkin wrote: > It will not block CI. > > > > > Best regards, > Mikhail > > *From:* Kari Oikarinen > *Sent:* Thursday, March 21, 2019 1:13 PM > *To:* Mikhail Svetkin; development@qt-project.org > *Subject:* Re: [Development] CMake branch > > > On 21.3.2019 14.00, Mikhail Svetkin 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? >> >> ** >> > > Would this have blocking CI or not? The stated disadvantage (which surely > shouldn't be entirely negative) implies that it would be. But the build being > nightly hints that it would not be. > > A blocking build would mean that all changes need to leave the CMake build > working. So everyone would need to take care of both build systems. A more > defined transition point and only one official build system at a time would be > nicer. Or at least trying to minimize the time of having two. > > Unless of course we'd already be ready to drop building Qt with qmake, but I > guess that's not where we are yet. Is that expected to happen during 5.x > series > at all or only with Qt 6? > > -- > Kari -- --- Kari Oikarinen Senior Software Engineer The Qt Company Elektroniikkatie 13 90590, Oulu, Finland kari.oikari...@qt.io +358 50 5281010 http://qt.io --- ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
> Could you explain the stated disadvantage further then? It's just about more integrations due to the cmake related patches. Best regards, Jesús From: Development on behalf of Kari Oikarinen Sent: 21 March 2019 13:23 To: Mikhail Svetkin; development@qt-project.org Subject: Re: [Development] CMake branch Could you explain the stated disadvantage further then? -- Kari On 21.3.2019 14.21, Mikhail Svetkin wrote: > It will not block CI. > > > > > Best regards, > Mikhail > > *From:* Kari Oikarinen > *Sent:* Thursday, March 21, 2019 1:13 PM > *To:* Mikhail Svetkin; development@qt-project.org > *Subject:* Re: [Development] CMake branch > > > On 21.3.2019 14.00, Mikhail Svetkin 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? >> >> ** >> > > Would this have blocking CI or not? The stated disadvantage (which surely > shouldn't be entirely negative) implies that it would be. But the build being > nightly hints that it would not be. > > A blocking build would mean that all changes need to leave the CMake build > working. So everyone would need to take care of both build systems. A more > defined transition point and only one official build system at a time would be > nicer. Or at least trying to minimize the time of having two. > > Unless of course we'd already be ready to drop building Qt with qmake, but I > guess that's not where we are yet. Is that expected to happen during 5.x > series > at all or only with Qt 6? > > -- > Kari ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On 21 Mar 2019, at 13:00, Mikhail Svetkin mailto:mikhail.svet...@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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
From: Development on behalf of Mikhail Svetkin >The disadvantages are: > - Any changes should be passed by CI 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. Hence a big disadvantage is the risk of Qt 5.14/5.15 releases without CI. If you want to do this use the wip/qt6 branch. People will want to work their eventually anyway but at least it's their decision when they get exposed. If you want to help, you don't need it to be in dev. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Hi all, On Thu, 2019-03-21 at 12:51 +, 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
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@qt-project.org Subject: Re: [Development] CMake branch On 21 Mar 2019, at 13:00, Mikhail Svetkin mailto:mikhail.svet...@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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
> 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@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@qt-project.org Subject: Re: [Development] CMake branch On 21 Mar 2019, at 13:00, Mikhail Svetkin mailto:mikhail.svet...@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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
> -Original Message- > From: Mikhail Svetkin > > 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. Indeed, it was a misunderstanding on my side. I thought you wanted to drop the blocking nature of the CI for cmake related issues and in turn all of Qt respectively. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
> -Original Message- > From: Development On Behalf Of > Mikhail Svetkin >>> - We can synchronize CMakeFiles and *.pro files > > I do not understand this part. > We can ask people to update CMakeFiles after updating pro files. I don't think that you can make this a requirement at this point in time. You may find super enthusiastic people but in general you cannot assume that they stay in sync at this early point in time. > > 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. You are contradicting yourself somewhat. Above you want to do this because it makes it much easier to keep the files in sync. At the same time you admit they don't change often. This would be an argument to keep the files contained to a side branch or maybe qt6 branch. I don't believe familiarity and very few changes to pro files is a good enough reason to have all the cmake files in our release repo for the next 5+ years. Please consider people who do not want to get involved in this process at this early stage. Generally, we always do feature development in feature branches. Otherwise you will annoy people who do not want to deal with it. If I do feature development in a side branch I have to regularly sync too. Such is the nature of the beast and containment of features and their inherent instability is a good development practise in general. Cmake is not different and apparently the sync problem between pro files and cmake files is minor anyway (by your own admission). > > 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. Do you know that you cannot even use a current cmake release to build qtbase? You need to make your own cmake build from an unreleased feature branch. I think you will find this will dampen the enthusiasm to take this up in the short term. > > 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. Please distinguish two points. One part is the decision to accept cmake as build system. The other is the decision to litter our dev branch for years to come with not needed files. The decision from the project does not require a merge request to Qt's dev branch. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On 21.03.19 17:01, Alex Blasche wrote: >>> 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. > Do you know that you cannot even use a current cmake release to build qtbase? > You need to make your own cmake build from an unreleased feature branch. I > think you will find this will dampen the enthusiasm to take this up in the > short term. The dependency to cmake HEAD is a temporary glitch until the .qrc conversion is complete. Once it is, the minimum required version of cmake is the latest release, 3.14.0. Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Am Donnerstag, den 21.03.2019, 15:26 + schrieb Mikhail Svetkin: > > I do not understand this part. > > We can ask people to update CMakeFiles after updating pro files. Creator has two build systems and that is a constant PITA. If we decide to do this, then we need to have one CMake build as part of the blocking CI. Otherwise we will not notice cmake breakage before it hits the tree. > > First it requires that we can not do *anything* that will break qmake while > porting to CMake. > > Why do we need to break qmake? We do not want to port all the qmake-quirks over to cmake. We get enough quirks for free straight from 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. > > If you want to move files you can update pro files and qmake build. The same > for another operations. The point is that you need to keep cmake and qmake in sync, whether or not that makes sense. E.g. the bootstrapping is not necessary in the same way with cmake -- so restructuring src/tools would make sense. That is not applicable to qmake, where the bootstrapping of qmake etc. is of course needed. We are not as free to change things for cmake in qt5/dev as we are with cmake in wip/qt6 -- where we can just remove all the .pro-files once cmake is there. We will not be able to do so in qt5/dev. I am not ruling out either option, but I do want to have this noted before we jump. > > 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. I expect more people will want to work on Qt than CMake, but I have no numbers to back this up:-) I *do* expect lots of developer will need to chip in to get the bulk of Qt ported to CMake. > Let's send a patch and see what happens. Sure. Any help getting wip/cmake updated to qt5/dev is appreciated! 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
Re: [Development] CMake branch
Hello, I really like the idea Mikhail proposed. I would even go as far as to add one platform where we start testing building Qt with CMake in the CI once we reach a level where we are comfortable with it. I think it makes sense to get the CMake port more exposed and let people play with it in a convenient way. In the best case, we could switch build system even earlier than Qt 6. For many users it's an implementation detail how Qt is built. The plan is to still build qmake and generate the needed pri/pro files so that applications can use qmake as their build system. For everyone that does build Qt themselves, moving to a more standard way of doing things (CMake rather than qmake) is an advantage, most people have to deal with cmake anyway. Doing simple changes to the build system are trivial in cmake and qmake (e.g. adding/renaming files and so on). More complex changes should be reflected in both. For this port to succeed, an incremental port where we can expand to more platforms and more modules seems most promising to me. I'd move over to cmake and ninja for my needs instantly if I could. Cheers, Frederik On torsdag 21. mars 2019 13:00:55 CET Mikhail Svetkin 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? > > Best regards, > Mikhail ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On Thu, Mar 21, 2019 at 03:06:18PM +, Mikhail Svetkin wrote: > > 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. There's probably indeed a misunderstanding here, so please clarify: I assume that currently changes to the cmake wip branch go into the repo directly, i.e. with a delay in the range of seconds. Is that correct? I read the proposal so that after the proposed change it will just be staged together with all the other change to Qt base and will be subject to the normal restaging cycles as other qtbase changes, i.e. with a delay in the range of hours and days. Is that interpretation correct? Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On 21.03.2019 19:10, André Pönitz wrote: > On Thu, Mar 21, 2019 at 03:06:18PM +, Mikhail Svetkin wrote: >>> 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. > > There's probably indeed a misunderstanding here, so please clarify: > > I assume that currently changes to the cmake wip branch go into the repo > directly, i.e. with a delay in the range of seconds. Is that correct? Yes > I read the proposal so that after the proposed change it will just be > staged together with all the other change to Qt base and will be subject > to the normal restaging cycles as other qtbase changes, i.e. with a delay > in the range of hours and days. Is that interpretation correct? Yes, even if it won't be tested on any of those integrations. > Andre' > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > - Mårten Nordheim ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Am 21.03.19 um 15:54 schrieb Tobias Hunger: > 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. > Tobias' last paragraph is key here. For this proposal to be implemented, a merge of wip/cmake with dev needs to be done, regardless. That works needs to be done first. We need help. I like the overall idea of trying this out in dev - we should dare to do this. If it doesn't work out and it slows everything down, then we can still go back and branch off of dev. If it works out as planned and yields more contributions, then we win. I think earlier last year we never considered this even, but today the quality of the .pro file converter has made this a possibility worth trying. It might be though that completing milestone 1 (QTBUG-73925) presents a more sensible point of convergence where we could bring this into dev. Mikhail, Jesus, what do you think? Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On 22.03.2019 09:58, Simon Hausmann wrote: I think earlier last year we never considered this even, but today the quality of the .pro file converter has made this a possibility worth trying. Is this converter available somewhere? We're currently planning to migrate a project from qmake to CMake, and evaluating the switch with such a converter would be a tremendous help! ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Hi, The script(s) are work in progress. You can find them in the util/cmake/ sub-directory of the wip/cmake branch of qtbase. There is one script for converting configure.json and one for converting .pro files. At the moment they are geared towards using the CMake functions we're developing in the same branch (in the cmake/ top-level sub-directory), but if you'd like to help make them work in a more general environment, then please don't hesitate to push patches to the wip/cmake branch in to Gerrit for review and pop by #qt-cmake on Freenode IRC for reviews :) Simon From: Development on behalf of Julius Bullinger Sent: Friday, March 22, 2019 10:06 To: development@qt-project.org Subject: Re: [Development] CMake branch On 22.03.2019 09:58, Simon Hausmann wrote: > I think earlier last year we never considered this even, but today > the quality of the .pro file converter has made this a possibility > worth trying. Is this converter available somewhere? We're currently planning to migrate a project from qmake to CMake, and evaluating the switch with such a converter would be a tremendous help! ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Hi, You can find it here https://code.qt.io/cgit/qt/qtbase.git/tree/util/cmake/pro2cmake.py?h=wip/cmake > On 22. Mar 2019, at 10:06, Julius Bullinger > wrote: > > On 22.03.2019 09:58, Simon Hausmann wrote: > >> I think earlier last year we never considered this even, but today >> the quality of the .pro file converter has made this a possibility >> worth trying. > > Is this converter available somewhere? We're currently planning to migrate a > project from qmake to CMake, and evaluating the switch with such a converter > would be a tremendous help! > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
I think it is not bad idea in general, but I think we need to wait only some of them (maybe only build qtsvg and qt5). I think instead of creating new branches in qt5 and qtsvg we need to work in dev. Best regards, Mikhail From: Development on behalf of Simon Hausmann Sent: Friday, March 22, 2019 9:58 AM To: development@qt-project.org Subject: Re: [Development] CMake branch Am 21.03.19 um 15:54 schrieb Tobias Hunger: > 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. > Tobias' last paragraph is key here. For this proposal to be implemented, a merge of wip/cmake with dev needs to be done, regardless. That works needs to be done first. We need help. I like the overall idea of trying this out in dev - we should dare to do this. If it doesn't work out and it slows everything down, then we can still go back and branch off of dev. If it works out as planned and yields more contributions, then we win. I think earlier last year we never considered this even, but today the quality of the .pro file converter has made this a possibility worth trying. It might be though that completing milestone 1 (QTBUG-73925) presents a more sensible point of convergence where we could bring this into dev. Mikhail, Jesus, what do you think? Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Sure, we don't have to be super strict about those sub-tasks -- I'm sure Alexandru can be reasoned with so that we find a sub-set :). Right now a merge from wip/cmake to dev just wouldn't work at all anyway (it would break the cmake build). Simon From: Mikhail Svetkin Sent: Friday, March 22, 2019 10:49 To: Simon Hausmann; development@qt-project.org Subject: Re: [Development] CMake branch I think it is not bad idea in general, but I think we need to wait only some of them (maybe only build qtsvg and qt5). I think instead of creating new branches in qt5 and qtsvg we need to work in dev. Best regards, Mikhail From: Development on behalf of Simon Hausmann Sent: Friday, March 22, 2019 9:58 AM To: development@qt-project.org Subject: Re: [Development] CMake branch Am 21.03.19 um 15:54 schrieb Tobias Hunger: > 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. > Tobias' last paragraph is key here. For this proposal to be implemented, a merge of wip/cmake with dev needs to be done, regardless. That works needs to be done first. We need help. I like the overall idea of trying this out in dev - we should dare to do this. If it doesn't work out and it slows everything down, then we can still go back and branch off of dev. If it works out as planned and yields more contributions, then we win. I think earlier last year we never considered this even, but today the quality of the .pro file converter has made this a possibility worth trying. It might be though that completing milestone 1 (QTBUG-73925) presents a more sensible point of convergence where we could bring this into dev. Mikhail, Jesus, what do you think? Simon ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On Friday, March 22, 2019 9:58:33 AM CET Simon Hausmann wrote: > Am 21.03.19 um 15:54 schrieb Tobias Hunger: > > > 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. > > > > > > > Tobias' last paragraph is key here. For this proposal to be implemented, > a merge of wip/cmake with dev needs to be done, regardless. That works > needs to be done first. We need help. > > > I like the overall idea of trying this out in dev - we should dare to do > this. If it doesn't work out and it slows everything down, then we can > still go back and branch off of dev. If it works out as planned and > yields more contributions, then we win. I think earlier last year we > never considered this even, but today the quality of the .pro file > converter has made this a possibility worth trying. > > > It might be though that completing milestone 1 (QTBUG-73925) presents a > more sensible point of convergence where we could bring this into dev. > Mikhail, Jesus, what do you think? > > > Simon Hi, 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(*). I'm also a bit afraid that we are making the same delivery mistake as with qbs. 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). 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? 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? 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. We can have some transition scripts so configure && make && make install somehow workflow works, but that is all. (*) 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. So are we sure that cmake is the way to go? If yes then let's go to dev. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On 3/21/19 5:01 PM, Alex Blasche wrote: - We can synchronize CMakeFiles and *.pro files >>> I do not understand this part. >> We can ask people to update CMakeFiles after updating pro files. > > I don't think that you can make this a requirement at this point in time. You > may find super enthusiastic people but in general you cannot assume that they > stay in sync at this early point in time. The experience in Qt Creator, which has qmake and qbs files, is that most people are making the effort to update both build systems. The missing adaptions to qbs files was always (and still is) done manually by Christian. Take-away is that you can expect people helping keeping the CMake files up to date, but you won't get around fixing things yourself. Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
On 3/21/19 5:39 PM, Tobias Hunger wrote: > We do not want to port all the qmake-quirks over to cmake. We get enough > quirks > for free straight from cmake:-) I believe that this means a reduced feature set for the CMake port. What kind of things do we expect to go away that we take for granted with the current build? And even if that is the case, why can't the qmake part be kept separate and left alone? Joerg ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake branch
Am Freitag, den 22.03.2019, 10:45 + 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 -- 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
Re: [Development] CMake branch
On Fri, Mar 22, 2019 at 12:53 PM Joerg Bornemann wrote: > I believe that this means a reduced feature set for the CMake port. That's not what I wanted to say:-) All buildsystems all have things where they are nice to use and other areas where they are less nice. I want a build system for Qt that uses the things that work well in cmake... one that does not do things for the only reason that we did it exactly like that with qmake. Things that make sense and where there is no obvious nicer way to get a similar effect in cmake should of course stay. > What kind of things do we expect to go away that we take for granted > with the current build? I do not plan to test any platform that I have no compiler for, so I expect things to break there. I hope those platforms that are relevant for Qt 6 will eventually get fixed by people that know them well. Things will change, but not all of them due to cmake: * We will also try to move most of the 3rd party code out of the Qt repositories -- as much as we can get away with. CMake is good at finding stuff, but we do this mostly since Thiago has been pushing for that even before we started with cmake. * We will also lose the ability to build qt tools for a host machine and then continue to build for a target machine. You will need a host installation to cross-compile. But again that is not due to cmake, but because Lars asked for this to avoid building host tools dozens of times on the CI. * Setting features, etc. will be done differently (via the cmake UIs). * How to enable sanitizers, etc. will change to how you do that in cmake. * I hope the builds will also become a bit more robust -- but not as robust as you would have managed with qbs! * Builds should be faster as well -- we remove 3rd party code, so there is less to build in the first place;-) There are lots more things. > And even if that is the case, why can't the qmake part be kept separate > and left alone? Currently the cmake and qmake parts are completely separate in the wip/cmake branch. But once cmake is functional I plan to remove the .pro/.pri/.qrc files and update some things then. E.g. we no longer need to bootstrap qmake, so we can remove some defines from Qt Base that enable that. In fact qmake does not even need to stay in qtbase when we can build everything with cmake. So I would like to separate that out so that we have the option of moving it into a separate repository. Whether or not we will move qmake is not my decision to make, but I do want to provide the option. Best Regards, Tobias ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
