From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15995 invoked by alias); 4 Oct 2012 00:50:28 -0000 Received: (qmail 15985 invoked by uid 22791); 4 Oct 2012 00:50:26 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,TW_XG X-Spam-Check-By: sourceware.org Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 04 Oct 2012 00:50:23 +0000 Received: by vbkv13 with SMTP id v13so9718680vbk.0 for ; Wed, 03 Oct 2012 17:50:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=7i9fV6cN7MSdW9FHZZ5UD46+EWLgX8ILljS2r9RuktQ=; b=Vsv7yhEBFzM7RxsPQ46m5Xxn6qzA+U3Bn5HBR5YU8Si4oH6jTsLTvTaXAx56DGaGei BYPjNazd6WcZpj7pErKQZR45jWJ7zprdeKyJ5OpDEyhrXPp7l0qKFbgBNMOjkKwsJ/RL RRtTW+zRf1n7mTNWy646fuH/5LIadpf7fSK/9h9Bj+stwBOYtwSROWPknjE23KhjrqRX n+Z/cW4nfwevCioVZ9L6F7XEddIE7fMSPr8AZpXdyoCF3sX1RuCcTjkMZfS+YWgq7ilT g0lotUbQNZml/ZEa/bYamTZdqMiy7FwSFr825Tbtc9mPbxmHpNA13T2uQFu4n7dma6vD huwg== MIME-Version: 1.0 Received: by 10.52.174.232 with SMTP id bv8mr1775600vdc.13.1349311822204; Wed, 03 Oct 2012 17:50:22 -0700 (PDT) Received: by 10.52.24.239 with HTTP; Wed, 3 Oct 2012 17:50:22 -0700 (PDT) In-Reply-To: <20121004000840.GI3028@adacore.com> References: <20120924145910.GE4146@adacore.com> <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> <20120927091737.GB2980@adacore.com> <20121004000840.GI3028@adacore.com> Date: Thu, 04 Oct 2012 00:50:00 -0000 Message-ID: Subject: Re: [PATCH] Also install data-directory into the build directory as computed by relocate_gdb_directory From: Doug Evans To: Joel Brobecker Cc: Khoo Yit Phang , Jan Kratochvil , GDB Patches Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmhRILI9W0gEZpewyyHIs2IL7OLi9N238n04XuZaA6Sc/JJqyWgYwYqzl1Lb0fN4Qkk1j8Mi4IfN7iiciuQQaprMPN7bn3ApLy9poCV5C1RjkkYeur/6gV/EcnXhMdiEq3yzMVdxQCA4TPrEGIfH7roXSOb2Z7Vn+7xogcjhHcC4468/DDwenKQbicUMr7iXkHDtfD0n3tc+b23PV7ccrnqa9cGEw== X-IsSubscribed: yes 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 X-SW-Source: 2012-10/txt/msg00052.txt.bz2 On Wed, Oct 3, 2012 at 5:08 PM, Joel Brobecker 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?