[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).
--
Joel
More information about the Gdb-patches
mailing list