From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28911 invoked by alias); 15 Dec 2008 16:46:34 -0000 Received: (qmail 28903 invoked by uid 22791); 15 Dec 2008 16:46:33 -0000 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Dec 2008 16:45:49 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 3FBD429004F for ; Mon, 15 Dec 2008 17:45:46 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6v7Hf+S2zw8x for ; Mon, 15 Dec 2008 17:45:45 +0100 (CET) Received: from province.act-europe.fr (province.act-europe.fr [10.10.0.214]) by mel.act-europe.fr (Postfix) with ESMTP id 8344C29000C for ; Mon, 15 Dec 2008 17:45:45 +0100 (CET) Received: by province.act-europe.fr (Postfix, from userid 560) id 804B2165C1A; Mon, 15 Dec 2008 17:45:45 +0100 (CET) Date: Mon, 15 Dec 2008 16:46:00 -0000 From: Jerome Guitton To: gdb@sourceware.org Subject: Re: global, target-specific, init files Message-ID: <20081215164545.GK34644@adacore.com> References: <20081214124549.GA25544@adacore.com> <20081214183532.GB28806@caradoc.them.org> <20081215115830.GI34644@adacore.com> <20081215154216.GA9832@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081215154216.GA9832@caradoc.them.org> User-Agent: Mutt/1.5.17 (2007-11-01) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00066.txt.bz2 Daniel Jacobowitz (drow@false.org): > Well, we took a full path. So you'd give it > $prefix/etc/$target-gdbinit in your case. The path automatically > relocates along with an installed GDB. Come to think of it, > I'm not sure entirely how to handle relocation if you want to source > another file in the same directory, but there's probably a logical > extension of the current mechanism for that. > > Does that clarify? It does; I understand now. And I like the way you fixed the problem, much simpler than my proposal. I have tested it and it works like a charm. Would it make sense to have this merged into the FSF tree?