[Development] Tracing Qt

Philip Ashmore contact at philipashmore.com
Mon Aug 26 14:45:04 CEST 2013

On 26/08/13 07:41, Koehne Kai wrote:
>> -----Original Message-----
>> From: development-bounces+kai.koehne=digia.com at qt-project.org
>> [...]
>>> For a tracing system to be useful and stand a chance of being adopted
>>> by the libraries used by Qt as well as Qt itself, it shouldn't be part of Qt.
>> [...]
>> The point of proposing a tracing system/library that's not part of Qt is that it
>> can be adopted by non-Qt libraries which Qt might eventually use.
> I don't agree. Let's not aim for an uber-tracing system that can (hypothetically) be used all over the stack. It's ambitious enough to have something that works for Qt + applications using Qt :) With an external framework you'd add yet another dependency to Qt, + nice integration with qDebug, QString etc is probably much more difficult. 
> Actually I agree with Alex: A lot of the ideas proposed are pretty much in line with the qlogger framework that was already heavily discussed a year ago. I planned to update + upload it for review for Qt 5.1, but other things got in the way ...
> Regards
> Kai
Sounds like qlogger could use v3c's tracing system as a back end, so I
don't see a problem.

My treedb project at SourceForge offers a malloc alternative that uses a
fuse filesystem - with tracing on the fuse side.

Just pointing out that the added dependency as you put it is really just
an option at configure time.

Use it, don't use it. Happy trails.

Philip Ashmore

More information about the Development mailing list