On Thursday, 21 February 2019 06:58:33 CET Simon Hausmann wrote: > I tend towards Alexandru’s approach for the sake of a maximal parallel > build. But it’s not evident yet whether this approach is feasible or > whether perhaps the external project solution gives better results in terms > of maintenance / correctness.
Heya, I agree, I'd first go into the direction Alexandru mentioned. To be honest, I personally try to stay away from CMake's ExternalProject as far as possible these days, having bitten by them badly a couple of times already. They just don't feel like they make anything easier, compared to running the commands yourself (main issue: you can't easily get a hold of the CMake targets created by a subproject in the superbuild; and you usually end up reimplementing parts of the CMake config files...). So, yep, add_subdirectory() sounds like the way to go; we'll need to check how that performs with the amount of existing Qt submodules, though. We might need to do a couple more optimizations of the CMake macros/functions in qtbase.git for that. Regards, Kevin > With other modules getting wip/cmake branches I can only invite to join, > experiment with “super builds” and contribute. We also have an irc channel > on Freenode, #qt-cmake. > Simon > > On 21. Feb 2019, at 00:28, Croitor Alexandru > <placi...@gmail.com<mailto:placi...@gmail.com>> wrote: > This is why for Qt For Python, we've opted to make a superproject that > doesn't use ExternalProejct, but rather uses add_subdirectory on each > subproject. The advantage is that you can open the superproject > CMakeLists.txt directly in Qt Creator, and get code completion and all the > goodies for the whole project. And users can still choose to build each > subproject separately (or rather that's what the CI does at the moment_. I > don't know whether that would be feasible for qt5 though, given there are a > lot more subprojects and files and targets. I'm mainly concerned with the > performance aspect of it. > On Wed, Feb 20, 2019 at 10:36 PM Matthew Woehlke > <mwoehlke.fl...@gmail.com<mailto:mwoehlke.fl...@gmail.com>> wrote: On > 13/02/2019 05.06, Simon Hausmann wrote: > > > We briefly discussed the topic and it's my understanding that an agreement > > exists to support two types of builds: > > > > > > > (1) Build a repo, install it, build the next repo, install it, etc. > > (2) Have a super-project that allows building all of Qt with one call > > to "cmake", a call to "cmake --build" and finally "$maketool > > install". > > > > > > > The latter has not been "developed" yet but I think it's necessary to > > allow for a convenient transition for the users of Qt. > > For (2), you might want to consider a "superbuild", i.e. a separate > CMake project that just builds a bunch of external projects¹, each of > which is a Qt module. > > Some advantages over a simple script or Makefile are that users can > select what modules they want, and you could probably set it up so that > users can choose what version of Qt they want to build (e.g. LTS, latest > release, dev, ...). > > The major disadvantage of "superbuilds" is they tend to be not-great for > people actually hacking on the code. > > (¹ https://cmake.org/cmake/help/latest/module/ExternalProject.html) > > -- > Matthew > _______________________________________________ > Development mailing list > Development@qt-project.org<mailto:Development@qt-project.org> > https://lists.qt-project.org/listinfo/development -- Kevin Funk | kf...@kde.org | http://kfunk.org
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
