> -----Original Message----- > From: Development <development-boun...@qt-project.org> 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
