[PATCH] Also install data-directory into the build directory as computed by relocate_gdb_directory

Joel Brobecker brobecker@adacore.com
Thu Oct 4 01:34:00 GMT 2012

> I think(!) this "can't happen" (if I understand the patch correctly),
> the installed directory will always be a subdir of $(top_builddir)/..
> It may be a useless subdirectory of $(top_builddir)/.., but at least
> it's in the build tree. :-)
> [Again, assuming I understand the patch correctly.]

You might be right - I might have missed that. But the patch cannot
be applied as is, as it relies on a GNU Make feature. So we were
going to adapt it to use sed instead.

> >   2. Accept the new situation, and configure with a --prefix somewhere
> >      in the build directory. I can do an install the first time, and
> >      then as needed based on what changes have been made since the
> >      last install...
> Not sure I understand, but for reference sake,
> Our builds always do a "make install" into a staging area, though we
> configure --prefix=/usr.

I finally figured out what DESTDIR is for. Almost like a chroot
kind of thing. Neat!

What I was saying is a little TMI for what we were discussing. It
was just an example of what I do to get something installed somewhere.
I could do it your way, but it's easier with a configure-time option...

> > It's a pain in the neck, but I think I have slowly been coming to
> > the conclusion that it is probably best for me, and the others who
> > were relying on this undocumented feature, to learn to live with
> > the new requirement. At least we tried...
> I'd be ok with a short option that said "I'm running from the build
> directory, deal with it." :-)
> E..g,
> bash$ ./gdb -b
> [alas -b is taken, but I hope you get the idea]

I don't think that it'll be necessary. Practically speaking, it's
easier to just do that one install, and keep it until some change
makes it need an update.

> Another wild idea is to rename the gdb in the build directory as xgdb
> (akin to xgcc).  One could key off that to know gdb is being run from
> the build directory.

I think that this is opening the door for allowing GDB to execute
code without the user being aware of it. I'd rather avoid that.

> btw, Is there a use-case of yours that I'm missing?

I do not think so. It's mostly a case where I build and then test
right away using the binary in the build directory. I've been doing
that for the past 12 years, and I find it saves time, albeit only
a little. I was exploring the idea of trying to preserve this
behavior. But I think the cost might be exceeding the benefits.

Thanks for looking into this with us, though. This is not to say
that the discussion is over; just that, so far, the options suggested
don't really help enough to be worth implementing (IMO).


More information about the Gdb-patches mailing list