Re: [PATCH] Relative source file search

[Craig Jeffree <craig dot jeffree at preston dot net>]

On Mon, 2005-10-03 at 21:35 -0400, Daniel Jacobowitz wrote:
> I took a brief look at it, and felt that it was in the wrong place,
> i.e. belonged in openp.  I haven't had a chance to come back to it yet.
> 

I considered this, however the information provided by the symtab
doesn't fit with this.  In the case that I'm experiencing I start up GDB
with a binary and issue this dir command:

dir /staff/taam/taam/bin/x86-Linux/nostrip/

which is the directory where the application was built.

When I do a "list GeAttribute.H:1" and break GDB at the start of
open_source_file() I get the following information in the symtab:

s->filename = "GeAttribute.H"
s->dirname = "../../../include/General"
s->fullname = 0x0

This dirname/filename concatenation is correct if taken relative to the
binary location added to the directory search path.

So open_source_file() calls find_and_open_source() which replaces
"$cdir" in the source search path with the value from s->dirname.
However this means the file cannot be found because openp() then
searches for the filename in each of the directories in the source
search path but this path now contains a relative path that depends on
one of the other entries in the path.

I don't think it makes sense for openp to start fiddling around with
combinations of directories from the path, however I can understand
wanting to move this into find_and_open_source() since open_source_file
() is meant to be a convenience function.

Would a move to find_and_open_source() instead of openp() be acceptable?

Cheers,
Craig.