[Qt-creator] Per project debug helpers and expending QTC variables in "Extra Debugging Helpers" setting

[André Pönitz]

> I was trying to add per project debugging helpers with QTC by using gdbinit file which
> doesn't seems to work. If I add something like this 'python
> exec(open('/some-path/qtc-helpers.py').read())' gdb loads the file without error while my
> classes are not decorated and this file works if loaded from QTC in "Extra Debugging
> Helpers".  So is there an error in the doc here?

It "works" in .gdbinit but takes a bit more code, currently sth like

    python sys.path.insert(1, '/data/dev/creator/share/qtcreator/debugger/')
    python import gdbbridge
    python gdbbridge.theDumper.addDumperModule({"path":"/tmp/qtc.py"}

This is likely to change over time, so I'd recommend to use the "Extra Debugging
Helpers" setting which will be adapted when this happens

> Then my second attempt was to add %{CurrentProject:Path}/qtc-helpers.py in "Extra Debugging
> Helpers", here while there is a little variable chooser widget, it seems that we can't use
> QTC variable here.  Looking quickly in the QTC code, this widget is a PathChooser which has
> a FancyLineEdit which doesn't seems to expend QTC variables maybe only ENV vars with
> Environment::expandVariables .

Bug.

> I'm not sure I'm right but this looks like two bugs? If yes I can do a bug report.

Feel free to.

> BTW, my main question is, did I miss a way to load per custom Debugging Helpers project?

No,  there isn't.

> I don't really understand why the default use case would be to make them global.
> When you
> work on different projects or when your classes change you have to update your Debugging
> Helpers. It would be more convenient to ship them with each project and QTC would detect
> them with some mechanism. This way it would ensure that helpers match current code.

That's in theory the Right Method, but in practice it breaks at least as often as
any other approach. A classic in that situation are incompatible Python versions
for dumpers for different libraries.

Having said that, applying a simple scheme like 'if there is a foo.so, check whether
there's a foo.so.pyqtc in reach' would make sense to me.

Andre'