On Thursday, 28 May 2020 10:19:58 PDT Adam Light wrote:
> I'm including generating moc files in "build time". I'm not saying that
> compiling the .cpp files will take significantly longer, but if a .cpp file
> has a #include "myclass.moc" type statement, that .cpp file has to be
> processed by moc
On 5/28/20 8:21 PM, Matthew Woehlke wrote:
if a .cpp file has a #include "myclass.moc" type statement, that .cpp
file has to be processed by moc
Huh?*Why*?
A direct use case of this is to support having Q_OBJECT classes defined
in a .cpp file. That requires moc to parse foo.cpp file and
On 28/05/2020 13.19, Adam Light wrote:
if a .cpp file has a #include "myclass.moc" type statement, that .cpp
file has to be processed by moc
Huh? *Why*?
AFAIK that's just... wrong.
MOC needs to process files that do metaobject things (e.g. use
Q_OBJECT). Including a .moc in a .cpp does not
On Thu, May 28, 2020 at 9:55 AM Oswald Buddenhagen <
oswald.buddenha...@gmx.de> wrote:
> On Thu, May 28, 2020 at 08:43:14AM -0700, Adam Light wrote:
> >> [include mocs]
> >>
> >Changing Qt in a way that would require #including the moc output from
> >the .cpp file might cause noticeable increase
On Thu, May 28, 2020 at 08:43:14AM -0700, Adam Light wrote:
[include mocs]
Changing Qt in a way that would require #including the moc output from
the .cpp file might cause noticeable increase in build times unless moc
is also changed.
care to explain how _exactly_ that would be the case?
On Wed, May 27, 2020 at 8:51 AM Thiago Macieira
wrote:
> On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
> > > this is not something we can subject our users to.
> >
> > orly? kde had been doing that for quite a while.
>
> And I fixed QtCore to do the same.
>
> The only reason
On Thursday, 28 May 2020 02:06:01 PDT Shawn Rutledge wrote:
> > On 2020 May 27, at 17:50, Thiago Macieira
> > wrote:>
> > On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
> >>> this is not something we can subject our users to.
> >>
> >> orly? kde had been doing that for quite a
Il 28/05/20 16:18, Matthew Woehlke ha scritto:
While that may be true, changing it now is going to break*every* user
that uses these methods to generate compound transformations... and
it'll be a silent break. I would be*very* surprised if that doesn't
generate more bug reports.
I 100%
On 27/05/2020 11.09, Giuseppe D'Angelo via Development wrote:
Sure, augmenting the docs would help. But the whole
point of the API is for its usage to be straightforward. If you do
QTransform t;
t.translate();
t.rotate();
t.scale();
auto result = t.map(foo);
the "obvious" meaning should be
this is not something we can subject our users to.
On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
>>> orly? kde had been doing that for quite a while.
On 2020 May 27, at 17:50, Thiago Macieira wrote:
>> And I fixed QtCore to do the same.
>>
>> The only reason not to
Thanks everybody!
Ivan.
> 28 мая 2020 г., в 10:50, Alex Blasche написал(а):
>
> Congrats to Ivan. Approver rights have been set.
>
> --
> Alex
>
>
> From: Development on behalf of Christian
> Kandeler
> Sent: Thursday, 7 May 2020 10:23
> To:
> On 2020 May 27, at 17:50, Thiago Macieira wrote:
>
> On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
>>> this is not something we can subject our users to.
>>
>> orly? kde had been doing that for quite a while.
>
> And I fixed QtCore to do the same.
>
> The only reason not
Congrats to Ivan. Approver rights have been set.
--
Alex
From: Development on behalf of Christian
Kandeler
Sent: Thursday, 7 May 2020 10:23
To: development@qt-project.org
Subject: [Development] Nominating Ivan Komissarov as approver
Hello,
I'd like
13 matches
Mail list logo
