[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: [KDE/Mac] Repository for patches to fix KDE Problems on OS X
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-06-29 5:58:14
Message-ID: 4999431A-3E39-451B-9BC9-96D5A44C20D6 () gmail ! com
[Download RAW message or body]

On 29/06/2014, at 1:14 AM, Marko Käning wrote:
> In fact, if you want to build the debug variant for a single port I am
> afraid that EVERYTHING, down to qt4-mac will have to be built as debug
> variants, which means you'd have to build everything from scratch and
> cannot get prebuilt binaries from our buildbots.

Marko, I don't think Qt *has* to be built in debug mode when KDE is.  I certainly
do not do that in my non-MacPorts build environment.  In the following snippet,
#4 is a Qt no-debug trace (no detail): #5 and #6 are KDE debug traces (lots of detail).

#4  0x0000000110f7d72d in QObject::disconnect ()
#5  0x000000010f80cf58 in Palapeli::MovePieceInteractor::stopInteraction
      (this=0x7fb470d22680, event=@0x0) at
      /kdedev/kde4.13/kdesrc/kde/kdegames/palapeli/src/engine/interactors.cpp:140
#6  0x000000010f80c21a in Palapeli::Interactor::setInactive () at
      /kdedev/kde4.13/kdesrc/kde/kdegames/palapeli/src/engine/interactor.h:122

Full debug in Qt is verbose and not a lot of use.  If your app (or the KDE libs) go
there and crash, it is usually because they have already done something bad,
like running past the end of an array or list or pointing to a deleted object.

Is the globality of variants in MacPorts perhaps the reason why KDE and Qt
both have to be built in debug mode?

Cheers, Ian W.

_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://community.kde.org/Mac
[prev in list] [next in list] [prev in thread] [next in thread]