On Monday, 10 January 2022 07:28:11 PST Edward Welbourne wrote:
> Presumably we have a tool - automoc ? - that scans our source to
> determine which headers need to be moc'd and which resulting moc output
> isn't already #include-ed, so needs separate compilation. We can surely
> adapt that tool t
Thiago Macieira (3 January 2022 15:10) wrote
[Referring back to unity builds.]
> Anyway, while this is great for reducing the number of build files,
> it's not a complete solution. It does point to one simple thing we
> should all do: includemoc. I think I've kept QtCore this way: all .cpp
> #inclu
On 1/3/22 2:40 PM, Lars Knoll wrote:
One other possible solution to improve compile times is the hack we used
15 years ago in KDE, where we grouped many .cpp files into one
compilation unit. There’s however a balance needed here, as it reduces
the efficiency of -j, but maybe compiling 4-8 .cpp
On 1/3/22 12:09 PM, Ulf Hermann wrote:
d, We used to build at least Qt itself with PCH by default. Why did we
change the default?
Building Qt with PCH is still the default.
Unless you're on macOS with CMake < 3.18 and build for multiple
architectures.
Cheers,
Joerg
___
> On 3 Jan 2022, at 16:10, Sérgio Martins wrote:
>
> On 2022-01-03 13:40, Lars Knoll wrote:
>> (...)
>> One other possible solution to improve compile times is the hack we
>> used 15 years ago in KDE, where we grouped many .cpp files into one
>> compilation unit. There’s however a balance neede
On Monday, 3 January 2022 12:10:04 -03 Sérgio Martins via Development wrote:
> It does make incremental builds slower, as then you need to recompile
> the entire amalgamation. For this reason I don't think
> it's a silver bullet.
It's not. Unless we're careful with the code we write, merging two .
On 2022-01-03 13:40, Lars Knoll wrote:
(...)
One other possible solution to improve compile times is the hack we
used 15 years ago in KDE, where we grouped many .cpp files into one
compilation unit. There’s however a balance needed here, as it reduces
the efficiency of -j, but maybe compiling 4-8
On 2022-01-03 08:43, Marc Mutz wrote:
Hi,
The Qt Creator folks have noted that compilation of Qt projects
against Qt 6.2 is sometimes almost twice as slow as it was in 5.15:
https://bugreports.qt.io/browse/QTBUG-97601
While we have some ideas where this may come from (including more std
headers
On Monday, 3 January 2022 10:40:42 -03 Lars Knoll wrote:
> One other possible solution to improve compile times is the hack we used 15
> years ago in KDE, where we grouped many .cpp files into one compilation
> unit. There’s however a balance needed here, as it reduces the efficiency
> of -j, but m
On Monday, 3 January 2022 11:05:25 -03 Philippe wrote:
> > The change to C++17 makes a huge difference too, regardless of PCH. That
> > #include in qglobal.h adds up to 300 ms in each build without
> > PCH, and a considerable amount with it too. And it gets worse with C++20
> > and ranges.
> I did
> The change to C++17 makes a huge difference too, regardless of PCH. That
> #include in qglobal.h adds up to 300 ms in each build without
> PCH,
> and a considerable amount with it too. And it gets worse with C++20 and
> ranges.
I did not notice any sensitive change when switching to C++20 (
On 3 Jan 2022, at 14:21, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
On Monday, 3 January 2022 05:43:53 -03 Marc Mutz wrote:
Hi,
The Qt Creator folks have noted that compilation of Qt projects against Qt
6.2 is sometimes almost twice as slow as it was in 5.15:
https://bugreports.
On Monday, 3 January 2022 08:09:39 -03 Ulf Hermann wrote:
> d, We used to build at least Qt itself with PCH by default. Why did we
> change the default?
I don't know about you, but I disabled PCH when I started using icecream for
distributed compiling about 5 years ago. It's incompatible with PCH
On Monday, 3 January 2022 05:43:53 -03 Marc Mutz wrote:
> Hi,
>
> The Qt Creator folks have noted that compilation of Qt projects against Qt
> 6.2 is sometimes almost twice as slow as it was in 5.15:
> https://bugreports.qt.io/browse/QTBUG-97601
>
> While we have some ideas where this may come fr
a) do we care
I care.
b) what metrics should we use to define success?
I don't care whether it uses PCH or not. It should do the fastest thing
by default. So, my metric is "time it takes to build " on my
machine. My favorite project is qtdeclarative, but I also build other
things.
c, Wh
Hi,
The Qt Creator folks have noted that compilation of Qt projects against Qt 6.2
is sometimes almost twice as slow as it was in 5.15:
https://bugreports.qt.io/browse/QTBUG-97601
While we have some ideas where this may come from (including more std headers,
qmetatype compile-time typename con
16 matches
Mail list logo
