QT_NO_STL in KDE4
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