Review Request 120510: [OS X] make debugger build (and functional = in progress)

[Milian Wolff]

> On Oct. 9, 2014, 12:14 p.m., Milian Wolff wrote:
> > Hello Rene.
> > 
> > I appreciate your work here, but this really is something that should not be done in the KDE4 based KDevelop code branches. There will be no future release of KDevelop 4 and adding new code there means you'll have to forward port these patches to frameworks manually.
> > 
> > "Simple" bug fixes in KDevelop 4 for your personal use are OK, but bigger things (which seem to be required to get GDB properly integrated) should go to frameworks.
> > 
> > That said, your time would also be better spent in getting LLDB integrated with KDevelop - again something that would need to be done for frameworks.
> > 
> > bye
> 
> René J.V. Bertin wrote:
>     Hi Milian,
>     
>     I know the future of KDevelop 4, just as well as you know, I hope, the current state of KF5 on OS X. We're MONTHS away of being able to use KF5 there, so while 1 (ONE) person works on basic KF5 support the others on the KDE-Mac team concentrate on improving KDE4 on OS X. We do aim to do that in a forward-looking way, so anything we do ought to benefit KF5 too.
>     So these are not simple bugfixes for my own personal use, but for the use of anyone who wants to use KDE on OS X (as well as possibly the legions of Linux users with distros that stick to KDE SC 4 until they judge KF5 ready ... which AFAIK is still the case for the brunt of them).
>     
>     I presume that the changes I present here will carry over rather directly to git/HEAD. 
>     
>     You're right though about lldb, and I was about to ask on #kdevelop if there were any plans to support that debugger outside of OS X (because I simply don't have the resources to do that alone). I just had a peak at Qt Creator: it uses Python bridges to talk with the 2 browsers, maybe an idea?
> 
> Milian Wolff wrote:
>     Sorry Rene, but adding support for GDB or LLDB in KDevelop is not just a bugfix. I will not accept that for our feature-frozen KDevelop 4 codebase. I'll happily review and integrate other bug fixes into KDevelop 4, but nothing that big. If you do not want to work on Frameworks, then please concentrate on the smaller things and ignore the bigger issues (such as this one).
>     
>     Regarding LLDB: reusing code from QtCreator might make sense indeed. And you are right that will will also help us on Linux and probably other platforms eventually. If you don't have the time for that, I can understand that perfectly fine. But please don't spent time on trying to get GDB on Mac running - it's (imo) a waste of time - especially on KDevelop 4.
>     
>     bye
> 
> René J.V. Bertin wrote:
>     ? There is already support for GDB in KDevelop, all I had to do to get it to work on OS X is make a few small changes to the code. Since the support was already there, I consider it a bugfix (following Albert's guidelines on that ;) ). Whether you include it is up to you, but I *would* appreciate constructive feedback if any can be given. Patches stand more chance of being discussed and corrected on here than on a MacPorts-specific site, even if their fate is to remain limited to that "distro".
>     
>     As to not wanting to work on KF5: that's only because I don't have the resources to work on a parallel KF5 install without messing up my production environment.
>     
>     In any event, it seems that GDB support on OS X is about as feature-complete as it'll get as far as KDevelop goes. The future of this endeavour will depend on GDB itself.
>     
>     How much change has there been to the debugger layer in KDevelop 5? In KDevelop 4 it's almost all concentrated in a single directory, if there are not (too many) ABI changes any work done re: lldb in the one version should benefit the other version. Again, KDE-Mac is stuck with KDevelop 4 for the foreseeable future ... and it seems self-evident that having a working debugger in KDE's native IDE cannot but help development, be it on KF5 or KDE4 (or more exactly, *on* KF5 *under* KDE4 ;) )

To quote you: "Getting the debugger to function is a work still in progress". So this patch s not yet enough to get GDB running on Mac, no? And GDB on Mac is a bad idea in itself (see LLDB).

I don't know how many changes there are, nor do I want to go and count them. That is the whole point of us putting a freeze on the KDE 4 codebase. We don't want to waste our time in forward-porting or resolving merge conflicts. Just adding qDebug/kDebug or includes is enough to break the build in master or reintroduce code that needs to be ported. We don't want that.

And there is support for GDB *on Linux*. Your patch shows that it never worked on Mac so complicating the code (which this patch does, by the ifdefs and such), is not a bugfix. If KDE-Mac sticks to KDE 4 then I'm afraid you'll have to live with the lack of a proper debugger. You are beating a dead horse.


- Milian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120510/#review68143
-----------------------------------------------------------


On Oct. 8, 2014, 10:03 p.m., René J.V. Bertin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/120510/
> -----------------------------------------------------------
> 
> (Updated Oct. 8, 2014, 10:03 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDevelop.
> 
> 
> Repository: kdevelop
> 
> 
> Description
> -------
> 
> The conditions are united under OS X / Macports to build kdevelop's debugger component: the changes to the CMake files take this into account.
> 
> Getting the debugger to function is a work still in progress for which I hope to get feedback/guidance via this RR.
> I have made the required changes in stty.cpp to obtain a pty with r/w permissions - on OS X this is done in a way that shares most code with the SGI code. In order not to duplicate more code than necessary I changed the logic of `ptyfd`'s initial value slightly, allowing to distinguish between uninitialised and error return values.
> 
> One has to install an uptodate gdb version (e.g. through MacPorts) and follow the instructions to give it the required permissions to function. Once that's done, the debugger component starts correctly, and appears to communicate with the gdb ("ggdb") slave process up to the point where the GUI is loaded and seemingly ready to go.
> 
> That's as far as I've gotten: even the "Interrupt" menu has no effect, the traceback panel shows no information either. Using the "stop all" button leads to a gdb crash; I have yet to determine what this is due to.
> 
> Feedback/guidance on how to procede will be appreciated.
> 
> 
> Diffs
> -----
> 
>   debuggers/gdb/gdb.h 6f99a60 
>   debuggers/gdb/gdb.cpp 68e1768 
>   debuggers/gdb/stty.cpp 736fff4 
>   debuggers/CMakeLists.txt 8fe222c 
>   debuggers/gdb/CMakeLists.txt 3d1125c 
> 
> Diff: https://git.reviewboard.kde.org/r/120510/diff/
> 
> 
> Testing
> -------
> 
> OS X 10.6.8 with kdelibs 4.14.1 and kdesdk git/kde4-legacy . Gdb 7.7.1 from MacPorts, compiled with python 2.7 support.
> 
> 
> Thanks,
> 
> René J.V. Bertin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20141009/6db79dda/attachment-0001.html>