+1 from me too
> On 18 Mar 2019, at 09:05, Ville Voutilainen wrote:
>
> Brett is the maintainer of Qt Remote Objects. Thus he should be
> documented as a maintainer, and should also be an approver. Brett has
> been effectively maintaining QRO since 2014, so it seems like a slam
> dunk to give
+1 from me as well!
> Il giorno 20 mar 2019, alle ore 01:57, Thiago Macieira
> ha scritto:
>
>> On Monday, 18 March 2019 01:05:22 PDT Ville Voutilainen wrote:
>> Brett is the maintainer of Qt Remote Objects. Thus he should be
>> documented as a maintainer, and should also be an approver. Brett
On Thu, Mar 21, 2019 at 03:06:18PM +, Mikhail Svetkin wrote:
> > I find it hard to believe that this improves the quality of Qt 5.14 or 5.15.
> > Effectively you are proposing that we don't have any blocking CI for those
> > two
> > Qt releases. Otherwise you would have to implement very intri
Hello,
I really like the idea Mikhail proposed. I would even go as far as to add one
platform where we start testing building Qt with CMake in the CI once we reach
a level where we are comfortable with it.
I think it makes sense to get the CMake port more exposed and let people play
with it in
Am Donnerstag, den 21.03.2019, 15:26 + schrieb Mikhail Svetkin:
> > I do not understand this part.
>
> We can ask people to update CMakeFiles after updating pro files.
Creator has two build systems and that is a constant PITA.
If we decide to do this, then we need to have one CMake build as
On 21.03.19 17:01, Alex Blasche wrote:
>>> We need volunteers for this! I do not see the team currently trying to
>>> port
>> Qtbase to CMake having the necessary resources.
>>
>> I think people do not want to just play with CMake. They want to build Qt
>> (in our
>> case QtBase) with CMake and i
> -Original Message-
> From: Development On Behalf Of
> Mikhail Svetkin
>>> - We can synchronize CMakeFiles and *.pro files
> > I do not understand this part.
> We can ask people to update CMakeFiles after updating pro files.
I don't think that you can make this a requirement at this
> -Original Message-
> From: Mikhail Svetkin
> > I find it hard to believe that this improves the quality of Qt 5.14 or 5.15.
> Effectively you are proposing that we don't have any blocking CI for those two
> Qt releases. Otherwise you would have to implement very intrinsic rules when
> t
> How so
They can use ninja.
> I do not understand this part.
We can ask people to update CMakeFiles after updating pro files.
> First it requires that we can not do *anything* that will break qmake while
porting to CMake.
Why do we need to break qmake?
> So no moving of files, no removal of
> I find it hard to believe that this improves the quality of Qt 5.14 or 5.15.
> Effectively you are proposing that we don't have any blocking CI for those
> two Qt releases. Otherwise you would have to implement very intrinsic rules
> when to block and when not to block. Even seemingly innocent
Hi all,
On Thu, 2019-03-21 at 12:51 +, Volker Hilsheimer wrote:
> The advantages are:
> - It allows our contributors to play with CMake in dev branch
> - Speed-up the build of QtBase
How so?
> - Easy to find a lot of bugs in CMake port
> - CI could have a nightly build with CMake and gen
From: Development on behalf of Mikhail
Svetkin
>The disadvantages are:
> - Any changes should be passed by CI
I find it hard to believe that this improves the quality of Qt 5.14 or 5.15.
Effectively you are proposing that we don't have any blocking CI
On 21 Mar 2019, at 13:00, Mikhail Svetkin
mailto:mikhail.svet...@qt.io>> wrote:
Hi everyone!
We’ve had an internal discussion about wip/cmake branch.
We thought maybe it is a good idea to merge wip/cmake into dev branch.
The advantages are:
- It allows our contributors to play with CMake in
> Could you explain the stated disadvantage further then?
It's just about more integrations due to the cmake related patches.
Best regards,
Jesús
From: Development on behalf of Kari
Oikarinen
Sent: 21 March 2019 13:23
To: Mikhail Svetkin; development@qt-pro
Never mind. The issue is of course that changes need to go through CI, even
though it doesn't check them.
--
Kari
On 21.3.2019 14.21, Mikhail Svetkin wrote:
> It will not block CI.
>
>
>
>
> Best regards,
> Mikhail
> --
Could you explain the stated disadvantage further then?
--
Kari
On 21.3.2019 14.21, Mikhail Svetkin wrote:
> It will not block CI.
>
>
>
>
> Best regards,
> Mikhail
>
> *From:* Kari Oikarinen
> *Sent:* Thursday,
It will not block CI.
Best regards,
Mikhail
From: Kari Oikarinen
Sent: Thursday, March 21, 2019 1:13 PM
To: Mikhail Svetkin; development@qt-project.org
Subject: Re: [Development] CMake branch
On 21.3.2019 14.00, Mikhail Svetkin wrote:
> *
>
> *
>
> Hi everyon
It should not be blocking for Qt 5.
We can generate a non-blocking integration report.
Best regards,
Jesús
From: Development on behalf of Kari
Oikarinen
Sent: 21 March 2019 13:13
To: Mikhail Svetkin; development@qt-project.org
Subject: Re: [Development] CMak
On 21.3.2019 14.00, Mikhail Svetkin wrote:
> *
>
> *
>
> Hi everyone!
>
>
> We’ve had an internal discussion about wip/cmake branch.
>
>
> We thought maybe it is a good idea to merge wip/cmake into dev branch.
>
>
> The advantages are:
>
> - It allows our contributors to play with CMak
Hi everyone!
We’ve had an internal discussion about wip/cmake branch.
We thought maybe it is a good idea to merge wip/cmake into dev branch.
The advantages are:
- It allows our contributors to play with CMake in dev branch
- Speed-up the build of QtBase
- Easy to find a lot of bugs in C
20 matches
Mail list logo
