Re: [Nemiver-list] source directories setting support

["Dodji Seketeli" <dodji domain hid>]

> Only now I'm thinking "Why can't we just get the full filename
> from the source editor?"  We clearly must know the full path in order
> to load the file, right? I assume there's a reason that this isn't
> feasible, but I was hoping you could just tell me before I go digging
> into the code too deeply :)

The thing is that there are several types of events that triggers a
source file loading in the source editor: debugger stopped at a line,
breakpoint set at a line, etc ...
Each of these events carry a source file name. Sometimes it carries
the full path to the source file name, sometimes it does not.

Let's a use case as an example.

1/the debugger stops at main.cc:10
2/nemiver loads bar.cc and shows a current line marker (the yellow
arrow) at main.cc:10
3/the user sets a breakpoints at bar.cc:20
4/nemiver shows a breakpoint marker (the red circle) at bar.cc:20.

If 2/ succeeds, it means nemiver got the fullpath to main.cc, say
/foo/bar.cc. That fullpath was found in the debug information
available in the "debugger-stopped" event.
So nemiver knows it has loaded /foo/main.cc in the source editor at this point.

This 2/ step could fail if no fullpath debug information is available.
In this case, we must have a source file directory list to look up the
source file. There is no way around it.

Now suppose we are about to do step 4/ and it happens that there is no
fullpath information available in the "breakpoint-set" event. Damn it.
At this point, we know that we have loaded /foo/bar.cc. What happens
in nemiver is that we try to see if we have "bar.cc" loaded, and that
request fails because we loaded /foo/bar.cc, not bar.cc. We could
fallback to /foo/bar.cc instead of searching bar.cc on the file system
again. That is definitely faster.

> > The user can now launch gconf-editor and edit the key
> > "/apps/nemiver/dbgperspective/source-search-dir" to set the list of
> > directories separated by a colon (':').
>
> Do you think this should be a 'global' setting? I.e. if I'm debugging
> my agave program in ~/Projects/agave.git/, I'll add a bunch of paths
> under this to my source-search-dirs setting.  But when I then debug a
> different app in a different location, there's no reason to search in
> my agave directory again.  So wouldn't it almost make more sense for
> this to be a session-related preference?  Or were you planning for
> this to be for "default" search locations, and also save a list of
> project-specific search paths in the session db?

Yes, that makes sense. Once we have the session management GUI (that
is capable of doing session properties editing) we can let the
debugging perspective get the source directories list from the current
debugging session.

> I will definitely work on the UI as soon as I have a good
> understanding of exactly how this is going to fit in with everything
> else

Nice. I also think we need to define de concepts of current debugging
session Vs saved debugging session Vs application wide settings a bit
better. I'll think about it and try to write a little something.


> I also fixed a couple little issues I had building the new changes.

Yeah, I have seen that, thank you very much.

Cheers,

Dodji.