Am Freitag, den 22.03.2019, 10:45 +0000 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