16.06.2019, 00:22, "Thiago Macieira" <[email protected]>: > On Saturday, 15 June 2019 12:22:34 PDT Bogdan Vatra via Development wrote: >> > Why must they be built in one go? Why can't they be separate builds >> > stitched together? Or even completely separate builds as on Linux and all >> > the other Unix? >> >> Because qmake can build them in one go and last but not least is very >> convenient. Because a "new" buildsystem should do more than the existing >> one, not less :). > > That only means a "nice to have", not "must have", feature. Sure it's > convenient, but how often do you really need both and can't simply build > twice? My Windows build is slow enough as is[*], I'd probably welcome the > separation. > > Note: with qmake's NMake generator, you *can* type "make debug" and it'll only > compile the debug sub-targets. That doesn't work with the Unix Makefile one, > so it won't work for macOS. > > [* because I build on my IT-provided dual-core laptop, which comes loaded with > IT-provided virus scanners, data-loss prevention tools, etc.] > >> > But it has the most support base and the most experience out there, which >> > was ostensibly the reason I posted. If users and packagers have problems, >> > the pool of people who can help is much bigger. >> >> IMHO "the most support base and the most experience out there" it's just >> an appearance, or at least all these "support" and "experience" doesn't >> apply to Qt, > > Sorry, I disagree. There being more users, more posts on StackOverflow, more. > I projects using it is not an appearance. It's a fact. Usually, that has a > strong correlation with quality and the ability to obtain help.
CMake is well-known for its ability to create artifical difficulties, so there is no wonder that there are more posts on StackOverflow :) > >> I'll reiterate a few examples : >> - no PCH (in decades) >> - no iOS (it seems we need to wait for 3.15 to have *some* support, let's >> not forget that iOS it's over a decade old) >> - no multi ABIs builds in one go (needed for msvc and useful also for >> Android). > > I'm not claiming those existed or discounting the value of having those. And > in the case of iOS builds, the absolute necessity thereof, before 6.0 is out. > > What I'm saying is that once we've got all the necessary pieces and we're > trying to build it, we will still have problems and my post was about ensuring > we had a robust enough tool and community to help us out. We will have > problems, whichever tool it is. My objective was to figure out how to solve > them afterwards. > > Granted, the iOS support being so new to the tool does not inspire > confidence... > >> My *hunch* is that 3.15 won't be enough to build all Qt platforms and >> we'll probably needs to wait a little bit more. IMHO cmake superiority it's >> just a myth, because, obviously, in *this moment* qmake is a superior >> buildsystem *for Qt*. > > Again, my post was not about technical superiority. It was about community and > robustness. > >> Again, I want to highlight the fact that I don't want to change TQC >> decision regarding Qt6 and CMake, my comments are only for the sake of the >> truth. > > And I will point out that this is not a TQtC decision, but a Qt Project > decision, although heavily influenced by the TQtC developers supporting the > company's position and that company's decision to cut development of the other > contender solution. > > BTW, the Meson developers contacted me after I posted my email last time and > asked if we were willing to investigate changing to it. But they didn't offer > and I didn't see anyone else stepping up to help us in the actual migration. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
