Author Topic: Including Python enabled GDB for MinGW?  (Read 2245 times)

Offline tigerbeard

  • Multiple posting newcomer
  • *
  • Posts: 104
Including Python enabled GDB for MinGW?
« on: March 17, 2016, 02:20:49 pm »
Hi all,

this is a follow up thread on,20270.0.html
As the thread was opened by Sap I did not want to fully pirate his topic.
You may check my last post in there for more details on how I got wxString watches working with my
C::B installation with MinGw. This thread focuses on the aspect of the setup and easy roll out of
the required python-enabled CDB.

Thus I install my compilers not in the C::B directory but on the same level as C::B itself. I found that seems to work for the debugger as well.

Code: [Select]

The gdb bin only has a gdb.exe and a gdbserver.exe and the printer scripts including their subdirs.

I have run the above setup for about 2 weeks now without problems and can really recommend it.

 - Non-Python enabled debuggers in new MinGw compiler installation can be ignored. Before they destroy pretty printing immediately
   upon installation.
 - Setting up Debugger for pretty printing according to the procedure in the forum is a bit complicated but needs to be
   done only once. No risk to lose it when updating compilers
 - slim Debugger installation
 - debugging wxString and correct display in Watch window
 - relocatable. Copy to C::B directory or anywhere else. Just adapt the Debugger path once.
 - Update debugger independently from Compiler
 - beginners (or people coming from Visual Studio) more clearly understand independency from compiler/debugger
 - path setting in C::B/Settings/Debugger/Default/ExecutablePath  is the same for both MinGw and MinGw-W64-32 compilers.
  - Installation of separate package Python 2.7, 32bit required
  - separate directory beside CodeBlocks (question of preference)
  - ?

The C::B team is providing a Full Setup of CodeBlocks for Windows including MinGW compiler on the download page.
I guess the motiviation is to make it easier for people to try out CodeBlocks and cross platform development (but
maybe I am wrong).

In my opinion its a bit unfortunate that when people take their first steps with wxWidgets as cross-platform
framework and they experience that great debugger integration in C::B with MinGw TDM, that they will fail to see
any wxString in the very good wxWidget sample projects (been there). For me that was a pretty strong annoying point
thats is coming back at you with almost every program you debug. Thats every day you work with the system.
Thats every day being annoyed and saying MS can do that so much better (ok, you got the point). But they do not know
 that C::B can do it a lot better, in fact (and you could even modify it...)

I can see strong reasons why its not possible to include a python enabled debugger into the C::B TDM package.
No volunteers can be asked to modify the standard TDM package manually for every release to replace the non-
python enabled cbd with a python enabled one. Thats aside possible legal issues, of course.

But today I am wondering if there was a way to include a python enhanced CDB as a standalone setup in the
Full Setup package? It would be independent of TDM itself and need not to be touched with newer versions.
Surly the major drawback would be the required python installation, but does that outweight the benefit?

Or maybe an additional download including the python 2.7.6.msi, recommended for users working with

I am convinced that would increase the number of people who not only try out C::B with wxWidgets
but also stick with it. At least it would make the full install the ready-to-rock package for C::B under
Windows which this IDE deserves.

looking forward to your discussion, Cheers,

PS: I tried to get the python enabled CDB running without the full python installation. I complains about a
missing python27.dll which I added from the python package. It did not complain any more but exited
immediately with a rather untelling message. The idea was to include the required Dlls directly with the
cdb.exe's to get a fully portable package. As I have no clue about phythons inner workings and setup
I could only continue by wild guessing which is probably not a good idea.