QtCreator debug helper
romain.pokrzywka at kdab.com
Mon Dec 27 21:24:46 CET 2010
On Sunday 26 December 2010 09:48:12 Pau Garcia i Quiles wrote:
> I'm trying to use QtCreator on Windows for KDE development. If you try
> a snapshot, a new debugger for MSVC-compiled code is available:
> In addition to install CDB, you need to build the debug helper
> libraries. The way emerge currently builds and installs Qt makes it
> impossible to build those helpers due to:
> * Private Qt headers are required. I see two solutions to this:
> a) Build Qt with "-developer-build" parameter to configure
> b) Modify qt.conf to make the includedir point to the Qt source
> directory. I think this is not a good idea.
> * Debug libraries. Debug helpers are built for debug and release.
> Currently, emerge only builds Qt in either debug or release
> configuration. Ideally, we should build Qt in both release and debug
> (add "-debug-and-release" to the configure parameters)
> * Given that Qt in debug tries to link to OpenSSL and DBUS debug
> libraries (with 'd' postix), we have two alternatives:
> a) Modify the Qt .pro files so that Qt is always linked to the
> flavor of DBUS and OpenSSL configured in EMERGE_BUILDTYPE (be it
> debug, release, relwithdebinfo, etc).
> - Advantages: only one build of DBUS and OpenSSL
> - Disadvantages: no DBUS or OpenSSL debug information once we
> enter DBUS or OpenSSL libraries, potentially troublesome (requires
> patching the Qt buildsystem depending on the configuration specified
> on the command line / kdesettings.bat; what if it's changed after
> building DBUS/OpenSSL/Qt ?)
> b) Build OpenSSL and DBUS in debug and release (release or
> relwithdebinfo) - Advantages: what Qt is expecting
> - Disadvantages: need to build and install DBUS and OpenSSL
> twice. OpenSSL has the same libraryname in debug and release. DBUS
> executables have the same name in debug and release. Emerge takes DBUS
> and OpenSSL from the work directory, not from the installed directory
> (according to the portage .py script, to avoid conflicting includes).
> Another alternative is to add QtCreator and the debug helpers to
> portage and modify the debug helper build system to build only debug
> or release but I don't really like it and could be a maintenance
> nightmare given the pace QtCreator is developed.
> What's your advice?
Adding -debug-and-release and -developer-build to Qt is straightforward (thanks for the tip btw, I didn't know that
triggered installing private headers too) . I wouldn't enable it by default though, but rather have it enabled based on
an environment variable or flag in kdesettings.bat.
For DBUS and OpenSSL it's a bit trickier indeed, but I'd go for your suggestion A) without hesitation.
It's definitely less effort to force Qt into using the library name or build we want than having to introduce a debug-
and-release build mechanism for DBUS and OpenSSL and then integrate that in emerge with all the side-effects it brings.
Plus, it really doesn't matter what we link against, as long as we can link, so it's fine to have both release and debug
builds of Qt linked agains a same build of DBUS and OpenSSL.
I see that for MYSQL we even provide an explicit library name in the configure.exe command line. Maybe we can do the
same with DBUS and OpenSSL and thus disable the automatic 'd' suffix addition, so this would solve the issue without
even having to modify Qt's buildsystem. But even if we have too in the end, then it would just be a small patch, which
is no big deal and quite easy to maintain.
So I suppose there's no option to limit the debug helpers to one build mode only ? IMHO this is worth a bug report /
feature request. It seems silly to have to build Qt in both modes just for that, especially if the absence of the second
build isn't handled in a better way than just failing.
Romain Pokrzywka | romain.pokrzywka at kdab.com | Certified Qt Software Engineer & Trainer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2396 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-windows/attachments/20101227/8f02af9c/attachment.p7s
More information about the Kde-windows