David Faure faure at kde.org
Wed Sep 13 15:56:05 BST 2006

On Wednesday 13 September 2006 12:59, Dirk Mueller wrote:
> On Wednesday 13 September 2006 10:59, Lubos Lunak wrote:
> > > Because kde3 did - that's the only reason so far.
> >  So we no longer care that it noticeably increases build times or it
> > doesn't do so anymore?
> Just my own small little benchmark: 
> $ make -j30 kdelibs r583758:
> real    9m2.265s
> user    7m58.346s
> sys     3m48.798s
> $ make -j30 kdelibs r583758 -DQT_NO_STL:
> real    6m16.271s
> user    5m53.586s
> sys     2m49.827s

Wow that's a large difference if it's indeed only due to -DQT_NO_STL.
Surprising, for just a few typedefs....

But then the best solution would be to do like we always did with exceptions: disabled
by default but can be enabled where needed. Similarly we could re-add QT_NO_STL by
default but allow CMakeLists.txt files to use remove_definitions(-DQT_NO_STL).

> But anyway, building time is unimportant. The point of -DQT_NO_STL was that no 
> STL crap sneeks into our code, so that: 
> $ du -sk b-with-stl/lib b-without-stl/lib
> 25826   b-with-stl/lib
> 25826   b-without-stl/lib
Strange line of argumentation; you are not proving that using stl algorithms instead
of hand-written code makes executables smaller or bigger, you are only saying that
we are not using them right now (so of course QT_NO_STL changes nothing).
You imply that with stl algorithms it would be worse, but this is no proof, it might well
be better when used properly.

David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

More information about the kde-core-devel mailing list