search

mauroc / squiddio_pi

squiddio_pi
3 stars 13 forks source link

recent commit breaks Eclipse/GDB debug #85

Closed mauroc closed 4 years ago

mauroc commented 4 years ago

this is really driving me nuts. I can't get eclipse to recognize the breakpoints I put in the squiddio_pi code.

I have painstakingly tracked down the offending commit by doing a binary search in the commit history, and recompiling each time: https://github.com/mauroc/squiddio_pi/commit/6da71fc67b13425a8f2550152bd830b9d05f8d91

The one right before it (https://github.com/mauroc/squiddio_pi/commit/37025a5fd63017a5475b0ed5846a8d2285ef4a5f) works just fine.

There are a number of environment variables being changed in that commit. My conclusion is that Eclipse/GDB uses one of those to know where the source code is located at run time, but I have no idea which one. I could start fiddling with the most suspect ones, but it would take me hours. Maybe one of you has a keen enough eye and understanding of C++ to send me in the right direction?

I have to believe there are other plugin admins out there using Eclipse, so this may become an issue. Thank you!

Running Eclipse version 2019-03 (4.11.0) Ubuntu 18.04

leamas commented 4 years ago

I have painstakingly tracked down the offending commit by doing a binary search in the commit history

You did that using git bisect, right?!

We really need some input from @jongough here. That said, the changes in 6da71fc are not about environment variables, it's just cmake variables which eclipse cannot see.

My 5 öre is that this is about installation paths and filenames which, at a glance, this seems to be all about.

jongough commented 4 years ago

I don't use Eclipse(too slow and cumbersome for me, I just seem to fight it all the time) I use KDevelop and it is working fine. As Alec says the change you are pointing to is only for packaging and only comes into play when 'make package' is used. For normal development runtimes this part of the cmake process is not used.

Have you tried creating a new clone of the repository and then opening that in Eclipse and seeing if it works? Have you tried deleting and recreating the build directory and running the complete cmake again? Both will only take a couple of minutes to do. I know I have problems with Visual Studio at times and just close the program, delete the build directory and run the cmake process again.

mauroc commented 4 years ago

Have you tried deleting and recreating the build directory and running the complete cmake

yes, multiple times. IN fact that's how I identified the "suspect" commit. Deleting build/ dir and recompiling with each different branch (@leamas : wish I had known about git bisect, but I essentially did manually what bisect does for you semi-automatically)

Have you tried creating a new clone of the repository and then opening that in Eclipse and seeing if it works?

no, but I'll try that

I use KDevelop and it is working fine

I may just bite the bullet and switch. Thanks for the lead. I can hardly recall an application that has ever brought me on the brink of insanity the way Eclipse has!

mauroc commented 4 years ago

solved by ditching eclipse in favor of kdevelop. Thanks for the advice @jongough