Re: [Development] CMake Workshop Summary

Although it seems to have been fixed for ninja : https://gitlab.kitware.com/cmake/cmake/merge_requests/430 On Mon, Feb 25, 2019 at 10:02 AM Jean-Michaël Celerier < jeanmichael.celer...@gmail.com> wrote: > > It is not bad, but it is not great either :-). For example one needs to > _link_ > QtCore

Re: [Development] CMake Workshop Summary

> It is not bad, but it is not great either :-). For example one needs to _link_ QtCore before compilation on other things can be started, it is quite visible on an under-powered machines, where linking takes time. I think that this would still generally be the case with CMake, there are longstand

Re: [Development] CMake Workshop Summary

On Mon, 25 Feb 2019 08:13:29 + Jedrzej Nowacki wrote: > On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote: > > But do note that our parallelism isn't that bad right now. > > It is not bad, but it is not great either :-). For example one needs to > _link_ > QtCore before com

Re: [Development] CMake Workshop Summary

On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote: > But do note that our parallelism isn't that bad right now. It is not bad, but it is not great either :-). For example one needs to _link_ QtCore before compilation on other things can be started, it is quite visible on an under

Re: [Development] CMake Workshop Summary

El domingo, 24 de febrero de 2019 13:58:17 -03 Thiago Macieira escribió: > On Sunday, 24 February 2019 08:08:39 PST Lisandro Damián Nicanor Pérez Meyer > wrote: > > For 5.11 something along: > > > > > > > > Note that only critical p

Re: [Development] CMake Workshop Summary

On Sunday, 24 February 2019 08:08:39 PST Lisandro Damián Nicanor Pérez Meyer wrote: > For 5.11 something along: > > > > Note that only critical path is followed, +/- docs. > > In other words: only 6 submodules can be built without

Re: [Development] CMake Workshop Summary

El miércoles, 13 de febrero de 2019 14:52:41 -03 Thiago Macieira escribió: > On Wednesday, 13 February 2019 09:08:58 PST Stephen Kelly via Development > > wrote: > > Of course it is easy to create a `Qt5or6::Core` target for transitional > > use > > and get all the benefits. > > > > target_link_l

Re: [Development] CMake Workshop Summary

Sorry for chiming in so late! El miércoles, 13 de febrero de 2019 11:40:15 -03 Tor Arne Vestbø escribió: > > On 13 Feb 2019, at 14:58, Kevin Funk via Development > > wrote: > > make it more difficult for distros to co-install the CMake config files > > for different Qt versions. > > This sound

Re: [Development] CMake Workshop Summary

El sábado, 23 de febrero de 2019 12:26:26 -03 Thiago Macieira escribió: > On Saturday, 23 February 2019 01:52:06 PST Richard Weickelt wrote: > > > But do note that our parallelism isn't that bad right now. There's a > > > long > > > critical path before parallel things can currently be built, but o

Re: [Development] CMake Workshop Summary

On Saturday, 23 February 2019 01:52:06 PST Richard Weickelt wrote: > > But do note that our parallelism isn't that bad right now. There's a long > > critical path before parallel things can currently be built, but once > > QtQml is built, the number of jobs that can be launched in parallel is > > v

Re: [Development] CMake Workshop Summary

> But do note that our parallelism isn't that bad right now. There's a long > critical path before parallel things can currently be built, but once QtQml > is > built, the number of jobs that can be launched in parallel is very big. What > doesn't need that build isn't very large. Could you e

Re: [Development] CMake Workshop Summary

On Thursday, 21 February 2019 02:59:20 PST Kevin Funk wrote: > 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 qtbas

Re: [Development] CMake Workshop Summary

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 mainten

Re: [Development] CMake Workshop Summary

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. With other modules getting wip/cmake branches I

Re: [Development] CMake Workshop Summary

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 who

Re: [Development] CMake Workshop Summary

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 Q

Re: [Development] CMake Workshop Summary

On Wednesday, 13 February 2019 09:08:58 PST Stephen Kelly via Development wrote: > Of course it is easy to create a `Qt5or6::Core` target for transitional use > and get all the benefits. > > target_link_libraries(mything PRIVATE Qt5or6::Core) That should plain be Qt::Core, which is the same as Q

Re: [Development] CMake Workshop Summary

> -Original Message- > From: Development On Behalf Of > Thiago Macieira > Sent: Wednesday 13 February 2019 16:36 > To: development@qt-project.org > Subject: Re: [Development] CMake Workshop Summary > > On Wednesday, 13 February 2019 05:58:18 PST Kevin Funk

Re: [Development] CMake Workshop Summary

On Wednesday, 13 February 2019 05:58:18 PST Kevin Funk via Development wrote: > The problem is, besides the reasons Simon mentioned, that just using "Qt" as > the package prefix will make it more difficult for distros to co-install > the CMake config files for different Qt versions. > > Still all

Re: [Development] CMake Workshop Summary

On Wednesday, 13 February 2019 02:22:15 PST Vitaly Fanaskov wrote: > It's not clear why you included version to a package name (e.g. Qt5/Qt6). > With CMake you can pass a version as the second argument, e.g.: > find_package(Qt 5.12) Perhaps it would be better, what do you think? Because applicatio

Re: [Development] CMake Workshop Summary

On Wednesday, 13 February 2019 02:06:13 PST Simon Hausmann wrote: > (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 > f

Re: [Development] CMake Workshop Summary

Simon Hausmann Sent: Wednesday 13 February 2019 12:53 To: Stephen Kelly ; Vitaly Fanaskov ; development@qt-project.org Subject: Re: [Development] CMake Workshop Summary I think the deliberate design choice to separate Qt4 and 5 visibly in the "API" (targets) was a wise choice at that

Re: [Development] CMake Workshop Summary

> On 13 Feb 2019, at 16:21, Tor Arne Vestbø wrote: > > Or, when building a distro-spesific package foo that depends on qt 5.12, the > distro would set CMAKE_PREFIX_PATH to the correct prefix. > > I think the latter is what Homebrew does. At least I think it does this for pkg-config. Tor Arn

Re: [Development] CMake Workshop Summary

> On 13 Feb 2019, at 16:13, Kevin Funk wrote: > > On Wednesday, 13 February 2019 15:40:15 CET Tor Arne Vestbø wrote: >>> On 13 Feb 2019, at 14:58, Kevin Funk via Development >>> wrote: > >>> make it more difficult for distros to co-install the CMake config files >>> for different Qt versions.

Re: [Development] CMake Workshop Summary

On Wednesday, 13 February 2019 15:40:15 CET Tor Arne Vestbø wrote: > > On 13 Feb 2019, at 14:58, Kevin Funk via Development > > wrote: > > make it more difficult for distros to co-install the CMake config files > > for different Qt versions. > > This sounds like a generally useful feature for d

Re: [Development] CMake Workshop Summary

> On 13 Feb 2019, at 14:58, Kevin Funk via Development > wrote: > > make it more difficult for distros to co-install the CMake config files for > different Qt versions. This sounds like a generally useful feature for distros to have, not just for major versions but for minor etc too? I gue

Re: [Development] CMake Workshop Summary

On Wednesday, 13 February 2019 11:22:15 CET Vitaly Fanaskov wrote: > Hi Simon, > > > Thank you for the update. > > > It's not clear why you included version to a package name (e.g. Qt5/Qt6). > With CMake you can pass a version as the second argument, e.g.: > find_package(Qt 5.12) Heya, We in

Re: [Development] CMake Workshop Summary

ay, February 13, 2019 12:32 To: Simon Hausmann; Vitaly Fanaskov; development@qt-project.org Subject: RE: [Development] CMake Workshop Summary As a deliberate design choice years ago, we put the major version in the package name because it avoids a class of user errors and confusion, and because

Re: [Development] CMake Workshop Summary

argument for example ☺. Thanks, Stephen. From: Development mailto:development-boun...@qt-project.org>> On Behalf Of Simon Hausmann Sent: Wednesday 13 February 2019 10:06 To: Alexandru Croitor mailto:alexandru.croi...@qt.io>>; development@qt-project.org<mailto:development@qt-project.org&g

Re: [Development] CMake Workshop Summary

, Stephen. From: Development On Behalf Of Simon Hausmann Sent: Wednesday 13 February 2019 10:47 To: Vitaly Fanaskov ; development@qt-project.org Subject: Re: [Development] CMake Workshop Summary That may be possible to implement. It requires the work to be done upstream in cmake's FindQt.

Re: [Development] CMake Workshop Summary

install". I don't think msbuild accepts a 'install' argument for example :). Thanks, Stephen. From: Development On Behalf Of Simon Hausmann Sent: Wednesday 13 February 2019 10:06 To: Alexandru Croitor ; development@qt-project.org Subject: Re: [Development] CMake Workshop S

Re: [Development] CMake Workshop Summary

refixed names already exist those could be used in that case, but if there are no Qt6:: prefixed target names, then that won't be possible in Qt6 to Qt7 transition? Thanks, Stephen. From: Development On Behalf Of Simon Hausmann Sent: Wednesday 13 February 2019 09:33 To: development

Re: [Development] CMake Workshop Summary

they think about it. Simon From: Development on behalf of Vitaly Fanaskov Sent: Wednesday, February 13, 2019 11:22 To: development@qt-project.org Subject: Re: [Development] CMake Workshop Summary Hi Simon, Thank you for the update. It's not clear why yo

Re: [Development] CMake Workshop Summary

Hi Simon, Thank you for the update. It's not clear why you included version to a package name (e.g. Qt5/Qt6). With CMake you can pass a version as the second argument, e.g.: find_package(Qt 5.12) Perhaps it would be better, what do you think? On 2/13/19 10:33 AM, Simon Hausmann wrote: Hi,

Re: [Development] CMake Workshop Summary

: Tor Arne Vestbø Sent: Wednesday, February 13, 2019 11:10 To: Simon Hausmann Cc: Alexandru Croitor; development@qt-project.org Subject: Re: [Development] CMake Workshop Summary > On 13 Feb 2019, at 11:06, Simon Hausmann wrote: > > (1) Build a repo, install it, build the next repo, instal

Re: [Development] CMake Workshop Summary

> On 13 Feb 2019, at 11:06, Simon Hausmann wrote: > > (1) Build a repo, install it, build the next repo, install it, etc. Will there be a -developer-build option that doesn’t require install? Tor Arne ___ Development mailing list Development@qt-pr

Re: [Development] CMake Workshop Summary

&& cd qtsvg && cmake && make install vs cd qt5 && cmake && make install ? From: Development on behalf of Simon Hausmann Sent: Wednesday, February 13, 2019 10:33:13 AM To: development@qt-project.org Subject: [Development] CM

Re: [Development] CMake Workshop Summary

; make install ? From: Development on behalf of Simon Hausmann Sent: Wednesday, February 13, 2019 10:33:13 AM To: development@qt-project.org Subject: [Development] CMake Workshop Summary Hi, On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate th

[Development] CMake Workshop Summary

Hi, On Monday/Tuesday a bunch of us met at KDAB offices in Berlin to accelerate the attempt of building Qt with CMake. I'd like to give a brief summary of this workshop. Who: Jean-Michaël, Liang, Volker, Mikhail, Kevin, me, Tobias, Kai and Albert. A very early visible artifact was the creation