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

[Doug Evans <dje@google.com>]

On Wed, Oct 3, 2012 at 5:08 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > Does anyone have any objection to this approach in principle?
>>
>> I'm not entirely comfortable with this yet, but I might be persuaded.
>
> I have to admit that I have been having second thoughts as well,
> trying to figure out all the implications of this change.
>
>> Alternative: Is there a robust enough test to determine gdb is being
>> run from its build directory?
>
> I don't see a robust way to determine that we are bing run from
> the build directory. I kind of see this approach as riskier than
> the first one.
>
> I've been mulling over the following two options:
>
>   1. Go with the idea of installing the data-directory inside the build
>      directory". But this assumes that the data-directory is relocatable,
>      and that it is a subdirectory of the prefix. If that's not the case,
>      then I think "make all" could end up installing the data-directory
>      at the configured location, outside the build directory. It seems
>      like an innocent thing, but in the end, I think it's bad - almost
>      sneaky.  I'd probably be the first one to curse if that happened
>      to me.

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.]

>   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.e. make install DESTDIR=$build/foo
[puts the entire gdb install tree in $build/foo/usr]

And, given gdb's relocatability, it "just works" (we configure with
values for --with-gdb-datadir and --with-system-gdbinit that are
relocatable).

One still can't run gdb from the build directory (without explicitly
passing --data-directory=foo), one needs to run gdb from the staging
area, but it lets us test without having to do a "make install" into
$prefix (e.g. /usr).
[Which isn't to say we don't also test the gdb installed in $prefix.]

> 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]

It's typed often enough that I can see myself getting use to it,
instead of forever avoiding "./gdb
--data-directory=$(pwd)/data-directory" because it's just too much to
type (even "make install DESTDIR=/foo" is too much to type after doing
"make" each and every time).
OTOH, one can always alias it: alias bgdb="./gdb --data-directory=foo"
(but that doesn't help debugging ./gdb in emacs).

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.

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