On Friday, 6 December 2019 15:10:41 PST Adam Light wrote:
> > Yes: https://github.com/qt/qtbase/blob/dev/util/includemocs/includemocs.pl
>
> Thanks. That saved a lot of time.
>
> For what it's worth, after changing all of our code to directly #include
> the moc output, the total build time
On Friday, 6 December 2019 10:06:24 PST Richard Weickelt wrote:
> > This solution gets you a single build for all the the mocs, which is good,
> > but won't generate the best code that Peppe was talking about. You want
> > the moc for a given class to be in the class's own .cpp.
>
> Unless you
On Friday, 6 December 2019 10:21:24 PST Michael Jackson wrote:
> Dear Thiago,
> Could you expand a bit on your comment? We use CMake for our build
> system and the AUOT_MOC feature. I just would like to know what exactly I
> am missing by doing this.
Run the includemocs script that I linked
On Fri, Dec 6, 2019 at 9:57 AM Thiago Macieira
wrote:
> On Friday, 6 December 2019 06:30:36 PST Adam Light wrote:
> > Yes, that's definitely on my TODO list, though I don't think it's going
> to
> > do much to address the current situation in which moc itself is the main
> > bottleneck. But any
Hi,
I’m giving a try to Qt 5.14 Preview on Android and when compiling an existing
project I’m having this:
In file included from
/Users/nsantos/Qt/5.14.0/android/include/QtGui/QGuiApplication:1:
In file included from
/Users/nsantos/Qt/5.14.0/android/include/QtGui/qguiapplication.h:43:
In
On 12/4/2019 9:31 AM, Roland Hughes wrote:
If you think auto won't be removed as a failed experiment, how about "new"?
Deprecated in C++20 and slated for removal in C++23.
https://www.modernescpp.com/index.php/no-new-new
Some more reading on the removal of pointers
On 12/6/19, 12:52 PM, "Interest on behalf of Thiago Macieira"
wrote:
On Friday, 6 December 2019 01:16:31 PST Kevin Funk via Interest wrote:
> On that note, CMake goes one step further and removes the need to do this
> manually. Using CMake's AUTOMOC feature, CMake will
> This solution gets you a single build for all the the mocs, which is good,
> but
> won't generate the best code that Peppe was talking about. You want the moc
> for a given class to be in the class's own .cpp.
Unless you build with link-time optimization enabled, I suppose. Because
then
> By the way: does anyone know about an implementation that avoids moc runs in
> a similar way how ccache avoids compile runs ?
You mean concatenating header and source files containing a Q_OBJECT macro
and feeding moc the result? I cannot imagine that this would be a safe
transformation in
On Friday, 6 December 2019 06:30:36 PST Adam Light wrote:
> Yes, that's definitely on my TODO list, though I don't think it's going to
> do much to address the current situation in which moc itself is the main
> bottleneck. But any improvement will help.
>
> Does anyone know of a script or other
On Friday, 6 December 2019 01:52:52 PST Giuseppe D'Angelo via Interest wrote:
> Sorry, not the code generated by moc -- the code generated by the
>
> compiler/linker. See e.g. here:
> > https://codereview.qt-project.org/c/qt/qtbase/+/152423
it also enables the "private member never used' warning
On Friday, 6 December 2019 01:16:31 PST Kevin Funk via Interest wrote:
> On that note, CMake goes one step further and removes the need to do this
> manually. Using CMake's AUTOMOC feature, CMake will automatically create ONE
> mocs_compilations.cpp file per target which in turn includes all
On Friday, 6 December 2019 00:42:22 PST Uwe Rathmann wrote:
> A side note: the code of Qwt project runs with all Qt versions >= 4.4
> and therefore allows to compare the impact of the Qt headers on the
> compile time. It is some time ago, when I did this, but the differences
> were significant.
I solved this problem, thanks all. So our previous video surface WAS
QPainter on a separate thread already, it is possible. It was also cross
platform. But, it was the deprecated QGLWidget.
It turns out even if I could have gotten this all working in QOpenGLWidget,
that newer widget had a bug so
On 11/22/19 2:14 PM, Roland Hughes wrote:
There have been many requests over the years to allow QPainter
operations outside of the primary thread. In particular for running
graphs like heart rate monitors which are just a brick on the screen the
user generally cannot interact with.
With X11
On 12/4/19 5:00 AM, Thiago Macieira wrote:
On Tuesday, 3 December 2019 17:36:37 PST Christian Gagneraud wrote:
My point is that this sort of bugs are really hard to detect during
code review. This is subtle & nasty 'feature' of QStringBuilder (a
choice in its implementation).
Understood, but
On 11/22/19 5:00 AM, Wesley Krasko wrote:
Thanks. For now anyways I'm trying to just move from QGLWidget to
QOpenGLWidget, buy time.
Can I get some help? In the QGLWidget one I currently have there is a
separate thread to render and it uses QPainter.
I'm trying to do the same for the new class
On Fri, Dec 6, 2019 at 12:42 AM Uwe Rathmann
wrote:
> On 12/6/19 2:09 AM, Adam Light wrote:
>
> > Does anyone else have any ideas of how we could change our build to
> > improve moc performance when Windows decides to be "slow"?
>
> Something you can try is to include the moc file at the end of
On 12/6/19 9:48 AM, Giuseppe D'Angelo via Interest wrote:
This trick is used in several places in Qt itself (look for "includemoc"
in commits). Not only it helps build times but also it produces slightly
better code overall.
By the way: does anyone know about an implementation that avoids
On Fri, 6 Dec 2019 08:23:20 +0530
Ramakanth Kesireddy wrote:
> When unit test binary(using cpputest to run the testcases + QTest for the
> specific Qt functionality)is executed on embedded target(linux), it doesnot
> shows any test summary/results with respect to number of testcases run on
>
Hi,
Il 06/12/19 10:48, Dmitriy Purgin ha scritto:
Hi Giuseppe,
> This trick is used in several places in Qt itself (look for "includemoc"
> in commits). Not only it helps build times but also it produces slightly
> better code overall.
Could you please elaborate what exactly do you mean
Hi Giuseppe,
> This trick is used in several places in Qt itself (look for "includemoc"
> in commits). Not only it helps build times but also it produces slightly
> better code overall.
Could you please elaborate what exactly do you mean under 'better code'?
How does including the xxx_moc.cpp
On Friday, 6 December 2019 09:48:51 CET Giuseppe D'Angelo via Interest wrote:
> Il 06/12/19 09:42, Uwe Rathmann ha scritto:
> > Something you can try is to include the moc file at the end of your cpp
> > file. This can be done like this:
> >
> > #include "moc_XYZ.cpp"
> >
> > This type of
Il 06/12/19 09:42, Uwe Rathmann ha scritto:
Something you can try is to include the moc file at the end of your cpp
file. This can be done like this:
#include "moc_XYZ.cpp"
This type of construction is at least supported by qmake.
This does not reduce the number of moc runs, but it reduces
On 12/6/19 2:09 AM, Adam Light wrote:
Does anyone else have any ideas of how we could change our build to
improve moc performance when Windows decides to be "slow"?
Something you can try is to include the moc file at the end of your cpp
file. This can be done like this:
#include
25 matches
Mail list logo
