Source directory trees not in build location

On Tue, Mar 28, 2006 at 05:57:33PM -0500, Bob Rossi wrote:
> On Tue, Mar 28, 2006 at 05:17:46PM -0500, Paul Koning
wrote:
> > We have a large source tree with many directories.
 When the system is
> > built that tree appears in one place in the
namespace; then the build
> > results are saved in "good builds"
directories, one per good build up
> > to whatever we can save.
> > 
> > The result is that source files are not where they
were at build time.
> > 
> > GDB can handle this on a per-directory basis with
the "directory"
> > command, but when you have on the order of a
hundred directories that
> > is excessively painful.
> > 
> > I made a local patch to add a source path name
rewriting rule.  That
> > allows a substring of the source path name to be
replaced by some
> > different substring.  The current implementation
is simplistic -- it
> > allows exactly one substitution rule, and the
matching is exact string
> > match.  It would be possible to allow multiple
rules, and probably
> > also fancier mechanisms like regexps.  That
wasn't necessary for our
> > application.
> > 
> > Is this of interest to the greater GDB?
> > 
> >    paul
> > 
> 
> Well, I'm not sure if that's necessary. Has anyone
gone back to this
> patch http://sourceware.org/ml/gdb-patches/2005-10/msg00092
.html?
> 
> Although, your solution seems really nice too.

Sorry, should have posted this link, it probably makes more
sense.
ht
tp://sourceware.org/ml/gdb/2005-08/msg00066.html

After reading it again, I'm not sure if this will solve
Paul's problem.
Paul, do you think it would?

This patch seems to have slipt through the cracks. I think
we should
look at it again.

Bob Rossi

On Tue, Mar 28, 2006 at 11:21:38PM -0500, Bob Rossi wrote:
> Sorry, should have posted this link, it probably makes
more sense.
> ht
tp://sourceware.org/ml/gdb/2005-08/msg00066.html
> 
> After reading it again, I'm not sure if this will
solve Paul's problem.
> Paul, do you think it would?

I don't think it will.

> This patch seems to have slipt through the cracks. I
think we should
> look at it again.

Yes, probably.  Reviewers are human too 

-- 
Daniel Jacobowitz
CodeSourcery