[Development] CMake branch

[Jedrzej Nowacki]

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