From: Craig Jeffree <craig.jeffree@preston.net>
To: Bob Rossi <bob@brasko.net>
Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
Subject: Re: [PATCH] Relative source file search
Date: Thu, 06 Oct 2005 23:33:00 -0000 [thread overview]
Message-ID: <1128641520.18954.63.camel@norman> (raw)
In-Reply-To: <20051006130035.GA6184@white>
On Thu, 2005-10-06 at 09:00 -0400, Bob Rossi wrote:
> Yes, this makes sense. Basically, the dirname is simply added to the
> source path, nothing else is done with it. AFAIK, the symtab will have
> the filename be what you gave to it on the compile line. For example,
> 'gcc -g ../main.c -o main' will give a filename of '../main.c', and if
> you do 'gcc -g main.c -o main', it will give a filename of 'main.c'.
> However, I'm not an expert on this.
I wonder how this works with header files, in my application for some
reason the filename ends up being split into dirname (the relative path
bit) and filename (just the actual filename). However in a little test
case I tried to make to reproduce it I ended up with an empty dirname
and the whole relative path+filename in filename. It's only the former
case that causes problems.
> Here's the current order looking for foo.c with
> dirname of '../src'
>
> 1. Look for foo.c
> 2. For each source_path, Look for source_path[i]/foo.c
>
> This case will search for 'foo.c' and '../src/foo.c'.
>
> The new search would be something like,
>
> 1. Look for foo.c
> 2. For each source_path, Look for source_path[i]/foo.c
> 3. Look for ../src/foo.c /* Not needed */
> 4. For each source_path, Look for source_path[i]/../src/foo.c
>
> This case will search for 'foo.c', '../src/foo.c', '../src/foo.c'
> and source_path[i]/../src/foo.c. The 3 case isn't needed, since it
> will be searched for in the second case.
>
> Is this what you are suggesting to change?
Not quite. I'm proposing "If dirname is absolute behave as it does now,
if dirname is relative prepend it to filename and treat dirname as
empty". This gives the new search from your example above to be...
1. Look for ../src/foo.c
2. For each source_path, Look for source_path[i]/../src/foo.c
I believe this is how it already behaves in all cases where the symtab
contains an empty dirname and a relatively pathed filename. Ideally we
should have consitent behaviour for the case where the relative path bit
is in dirname.
Cheers,
Craig.
next prev parent reply other threads:[~2005-10-06 23:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-27 7:42 Craig Jeffree
2005-10-04 1:24 ` [PATCH] " Craig Jeffree
2005-10-04 1:35 ` Daniel Jacobowitz
2005-10-06 0:57 ` Craig Jeffree
2005-10-06 2:16 ` Bob Rossi
2005-10-06 2:49 ` Craig Jeffree
2005-10-06 13:00 ` Bob Rossi
2005-10-06 23:33 ` Craig Jeffree [this message]
2005-10-07 0:25 ` Bob Rossi
2005-10-10 4:57 ` Craig Jeffree
2005-10-10 10:46 ` Bob Rossi
2005-10-10 16:46 ` Bob Rossi
2005-10-10 16:47 ` Daniel Jacobowitz
2005-10-10 23:15 ` Craig Jeffree
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1128641520.18954.63.camel@norman \
--to=craig.jeffree@preston.net \
--cc=bob@brasko.net \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox