John Cortell wrote:
Indeed. My proposal wouldn't solve, e.g., the case where
the user creates
a new launch configuration for the executable. We could look,
as
you suggest, to change where we house source locators, but I imagine
using the project wouldn't be ideal, either. I think, e.g., that the
CDT
Exectuables view uses a single project to house (provide the context
for)
any number of executables.
I don't claim to have the answer here, but collectively we should be
able to come up with one :-)
Not to mention, uprooting the source locators
would be very disruptive.
Not necessarily. The source locators implementation is very flexible,
I think it's just missing some key APIs. I would be glad to advise,
review, and commit whatever debug platform changes would be needed.
Cheers,
Pawel
John
At 12:02 PM 5/26/2009, Pawel Piech wrote:
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?
Cheers,
Pawel
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.
John
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
