Thank you Eike and André for your help :)
Le jeudi 06 septembre 2018 à 07:35 +0000, André Pönitz a écrit :
> > 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"}
Makes sense, I though it was weird that qtc would find dumper functions
by just loading my script in gdb.
>
> 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.
https://codereview.qt-project.org/#/c/238974/
This a is quite trivial patch and makes me using gerrit...
>
> > 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.
Yeah or anything that would detect project wide helpers. Maybe
buildsystem generator variables would also be enough.
>
> Andre'
>
> _______________________________________________
> Qt-creator mailing list
> Qt-creator@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator
_______________________________________________
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
