Re: [cdt-dev] CSourceNotFoundEditor
I also agree that this is a big usability problem. But it seems to be
that the suggested solution is somewhat of a band-aid approach. Does
anyone have any ideas (and maybe time to contribute) to fix this
properly in platform? One option may be to store source lookup
information separately from rest of launch configuration settings. For
example, if the executable is in the workspace, source lookup
information could be stored in the project meta-data. If it's not in
workspace, maybe preferences is the correct place?
John Cortell wrote:
When the user steps into a function during a debug session, and the
file containing that function can't be found, a mostly-empty editor is
shown. It contains a button that allows the user to "locate" the file.
So that the file can be found again in future debug session, CDT adds
a path mapping to the launch configuration which spawned the debug
session. This is very useful.
However it could do better. Say the user terminates that debug
session, and invokes another launch configuration which debugs the
same executable. He steps into that same function. He gets the special
editor again that asks him to locate the file. He grunts; he just
spent 20 seconds telling the debugger where it is. Did it forget
already? This scenario is common in multicore.
What I'm thinking of doing is enhancing the logic in
CSourceNotFoundEditor to have it add the mapping to all launch
configurations which reference the executable being debugged. I'm
polling to see whether this is behavior the community wants. If so,
I'll contribute it.
cdt-dev mailing list