From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31578 invoked by alias); 4 Oct 2012 01:34:16 -0000 Received: (qmail 31381 invoked by uid 22791); 4 Oct 2012 01:34:15 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO,TW_XG X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 04 Oct 2012 01:34:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 73DF71C7DD9; Wed, 3 Oct 2012 21:34:07 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sjOEWVFtR04x; Wed, 3 Oct 2012 21:34:07 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 16A981C7DE0; Wed, 3 Oct 2012 21:34:07 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id BA820C687C; Thu, 4 Oct 2012 03:33:58 +0200 (CEST) Date: Thu, 04 Oct 2012 01:34:00 -0000 From: Joel Brobecker To: Doug Evans Cc: Khoo Yit Phang , Jan Kratochvil , GDB Patches Subject: Re: [PATCH] Also install data-directory into the build directory as computed by relocate_gdb_directory Message-ID: <20121004013358.GJ3028@adacore.com> References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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/msg00053.txt.bz2 > 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.] You might be right - I might have missed that. But the patch cannot be applied as is, as it relies on a GNU Make feature. So we were going to adapt it to use sed instead. > > 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 finally figured out what DESTDIR is for. Almost like a chroot kind of thing. Neat! What I was saying is a little TMI for what we were discussing. It was just an example of what I do to get something installed somewhere. I could do it your way, but it's easier with a configure-time option... > > 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] I don't think that it'll be necessary. Practically speaking, it's easier to just do that one install, and keep it until some change makes it need an update. > 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. I think that this is opening the door for allowing GDB to execute code without the user being aware of it. I'd rather avoid that. > btw, Is there a use-case of yours that I'm missing? I do not think so. It's mostly a case where I build and then test right away using the binary in the build directory. I've been doing that for the past 12 years, and I find it saves time, albeit only a little. I was exploring the idea of trying to preserve this behavior. But I think the cost might be exceeding the benefits. Thanks for looking into this with us, though. This is not to say that the discussion is over; just that, so far, the options suggested don't really help enough to be worth implementing (IMO). -- Joel