From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4974 invoked by alias); 7 Feb 2014 21:00:00 -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 4954 invoked by uid 89); 7 Feb 2014 20:59:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 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; Fri, 07 Feb 2014 20:59:58 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s17KxtEI027141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Feb 2014 15:59:55 -0500 Received: from barimba (ovpn-113-148.phx2.redhat.com [10.3.113.148]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s17Kxshd000543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 7 Feb 2014 15:59:55 -0500 From: Tom Tromey To: Pedro Alves 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> Date: Fri, 07 Feb 2014 21:00:00 -0000 In-Reply-To: <52F50A87.6000907@redhat.com> (Pedro Alves's message of "Fri, 07 Feb 2014 16:32:07 +0000") Message-ID: <87bnyi1vw5.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-02/txt/msg00224.txt.bz2 >> -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. 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. 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; 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. Tom