Hi,
I want to let QtCore and QtGui etc. modules static linked against with one
pre-compiled achieve object.
So could someone help how to modify the qmake.conf under the related mkspecs
folder ?
Many thanks ;)
Thanks,
Song
___
Development mailing list
On Sunday 20 May 2012 02:17:53 Olivier Goffart wrote:
> You can see it works by trying the attached wrapper.c
Actually, I realize my implementation of the hook for tryLock was wrong as i
forgot the return value.
Fixed, just in case someone wants to use it.
--
Olivier
Woboq - Qt services and
On Saturday 19 May 2012 19:05:58 Thiago Macieira wrote:
> On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote:
> > Hi,
> >
> > Regarding valgrind:
> > *) On debug build, nothing is inlined.
> > *) If we keep it inline, then we would just need a patch like this [1]
>
> -fno-inline does
What platform are you using? Have you waited until the saving is done?
--
Sent from my Nokia N9
On 19.5.2012 16:44 Nicola De Filippo wrote:
Hi,
I'm developing a calendar with QML, with qorganizer mkcal backend. I noticed
that if I use backend memory and i save a OrganizerEvent with OrganizerM
Hello All,
As I'm keen on contributing to improve out documentation, I took the
liberty to put up on the wiki a session outline for what I hope will
be a productive doc sessions including (if time permits) thoughts of
beyond 5.0 and following hack sessions to get some of the new
decisions started
On sábado, 19 de maio de 2012 10.48.22, Charley Bay wrote:
>
>
> I've followed this very technical discussion from the beginning--
> impressive array of topics. Thanks to all digging into this, and great
> thanks to Thiago for opening the issue.
>
> I have a question on the point of "recursive-lo
On sábado, 19 de maio de 2012 18.34.30, Olivier Goffart wrote:
> Hi,
>
> Regarding valgrind:
> *) On debug build, nothing is inlined.
> *) If we keep it inline, then we would just need a patch like this [1]
-fno-inline doesn't help because of -fvisibility-inlines-hidden. The call
cannot be rerou
I've followed this very technical discussion from the beginning--
impressive array of topics. Thanks to all digging into this, and great
thanks to Thiago for opening the issue.
I have a question on the point of "recursive-locks":
I understand "recursive-locks" (e.g., "recursive-lock-count") we
On Wednesday 16 May 2012 23:49:42 John Layt wrote:
> Actually removing the "abstract" base class is just a case of
> s/QAbstractPrintDialog/QPrintDialog and tweaking the constructors, as the
> class is not really abstract, the only virtual method is exec(), nothing
> else gets reimplemented in the
> When would alpha 2 happen?
I am also interested in that information.
Best Regards,
Laszlo Papp
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Hi,
Regarding valgrind:
*) On debug build, nothing is inlined.
*) If we keep it inline, then we would just need a patch like this [1]
Regarding Transactional memory:
*) Very interesting
*) Notice the end of section 8.2.1: "Improper use of hints will not cause
functional bugs though it
On Saturday 19 May 2012 07:30:56 lars.kn...@nokia.com wrote:
> A few comments from my side:
>
> * I am not a big fan of inlining the public classes neither. It feels a
> bit like over-optimizing at the wrong place. Reason is that this might
> make it a impossible later on to refactor our code.
In
Hi,
I'm developing a calendar with QML, with qorganizer mkcal backend. I noticed
that if I use backend memory and i save a OrganizerEvent with OrganizerModel
of QML is all ok, but if I use mkcal not save anything. i'm forced to save
invoking a C + + function. I searched the bugs, but I have not
On sábado, 19 de maio de 2012 10.26.03, Thiago Macieira wrote:
> > But fast uncontended case is critical because it allows the use of mutex
> > in
> > part that might or not be used with threads. Example: QObject. We need to
> > put mutexes while emiting a signal because maybe it is used in multipl
On sábado, 19 de maio de 2012 07.30.56, lars.kn...@nokia.com wrote:
> * it would be good to see how much of a real world (ie. not with
> artificial benchmarks) difference you get due to inlining the mutex code.
> Is it really relevant?
Here's a suggestion for one: the Creator C++ parser. I remembe
On sábado, 19 de maio de 2012 00.36.56, Olivier Goffart wrote:
> On Friday 18 May 2012 23:25:47 Thiago Macieira wrote:
> > > Which non-negligible performance penalty are you takling about here?
> >
> > The need to allocate memory and do the test-and-set loop for setting the
> > private.
>
> There i
A few comments from my side:
* I am not a big fan of inlining the public classes neither. It feels a
bit like over-optimizing at the wrong place. Reason is that this might
make it a impossible later on to refactor our code.
* It's ok to have some low level inline class for internal use if that
hel
17 matches
Mail list logo
