[Development] CMake Workshop Summary

[Kevin Funk]

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
> <placinta at gmail.com<mailto:placinta at 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.floss at gmail.com<mailto:mwoehlke.floss at 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 at qt-project.org<mailto:Development at qt-project.org>
> https://lists.qt-project.org/listinfo/development


-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190221/ec53683a/attachment.sig>