From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12263 invoked by alias); 10 Feb 2014 13:27:07 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 12253 invoked by uid 89); 10 Feb 2014 13:27:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Feb 2014 13:27:06 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1ADQs6G019717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Feb 2014 08:26:54 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1ADQpNp027115; Mon, 10 Feb 2014 08:26:52 -0500 Message-ID: <52F8D39B.50908@redhat.com> Date: Mon, 10 Feb 2014 13:27:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tom Tromey CC: Yao Qi , gdb-patches@sourceware.org Subject: Re: [RFC 1/2] link gdbserver against libiberty References: <1390243792-31176-1-git-send-email-tromey@redhat.com> <1390243792-31176-2-git-send-email-tromey@redhat.com> <52DDD1BA.7050202@codesourcery.com> <87y51n0yh4.fsf@fleche.redhat.com> <52F50A87.6000907@redhat.com> <87bnyi1vw5.fsf@fleche.redhat.com> In-Reply-To: <87bnyi1vw5.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00299.txt.bz2 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