This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Also install data-directory into the build directory as computed by relocate_gdb_directory
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Khoo Yit Phang <khooyp at cs dot umd dot edu>, Jan Kratochvil <jan dot kratochvil at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>
- Date: Wed, 3 Oct 2012 18:33:58 -0700
- Subject: Re: [PATCH] Also install data-directory into the build directory as computed by relocate_gdb_directory
- References: <2878953E-B698-43F3-989A-A551D96BAB62@cs.umd.edu> <20120924152641.GF4146@adacore.com> <9F52A338-A158-44DC-90C1-F46503859613@cs.umd.edu> <285502C6-1395-4049-9D55-031EDA3AD06D@cs.umd.edu> <20120924170348.GI4146@adacore.com> <CC9CEDC8-8941-43A8-88EA-DAB1B671DD32@cs.umd.edu> <20120927091737.GB2980@adacore.com> <CADPb22Q1a2TJ_bR0yq_wjOua8pBqBsZXvyS2uteX9xKiLuC9kw@mail.gmail.com> <20121004000840.GI3028@adacore.com> <CADPb22TcGqvuxKo5_t8zuwNiJyUL4Yp38zA0OXcX_Dbv9bmyNQ@mail.gmail.com>
> 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