Re: [RFC 1/2] link gdbserver against libiberty

[Pedro Alves <palves@redhat.com>]

On 02/07/2014 08:59 PM, Tom Tromey wrote:
>>> -SUBDIRS = $(GNULIB_BUILDDIR)
>>> +SUBDIRS = $(GNULIB_BUILDDIR) $(LIBIBERTY_BUILDDIR)
>>> CLEANDIRS = $(SUBDIRS)
>>> +INSTALLDIRS = $(GNULIB_BUILDDIR)
> 
> Pedro> I understand making sure we don't try to install anything from
> Pedro> libiberty.  Preexisting to this patch, but I wonder why we even
> Pedro> run make install in gnulib.  Seems that like with libiberty,
> Pedro> we wouldn't ever want to install anything built in gnulib
> Pedro> subdir.
> 
> On the one hand it is odd; but on the other it can be argued for from a
> black-box perspective.  

Agreed.

I had actually assumed the reason would be that a single gdb build
that included gdbserver would end up installing libiberty twice.
But, libiberty doesn't really install anything actually without
--enable-install-libiberty (which moving to toplevel would sort out).

> The reason I skipped this for libiberty is that
> gdb uses its own "install-only" target when entering subdirs; but this
> is neither GNU nor generally used in the rest of the tree.  So, it
> caused installation to fail.

OK.  That was not obvious at all though.  If this stays, can you
add this info somewhere (source or commit log)?

> It's possible to fix this another way, say entering libiberty and using
> the "install" target there.  But it seems not worth the effort to me;

Well, looking at gdb's own Makefile, we see that install-only there
already punts on "-only" when recursing, therefore never escaping
that gdb-specific target elsewhere:

gdb's Makefile:

install-only: $(CONFIG_INSTALL)
...
        @$(MAKE) DO=install "DODIRS=$(SUBDIRS)" $(FLAGS_TO_PASS) subdir_do

It's just that gdbserver's currently doesn't.  Seems quite easy to
do and just less magic.

> first because we don't want to install anything in libiberty (unless one
> highly values the black box approach, which I do not); and second
> because eventually I will be moving all this stuff to the top-level
> anyway.

OK.

Thanks,
-- 
Pedro Alves