From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32601 invoked by alias); 13 Jun 2017 17:29:22 -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 30905 invoked by uid 89); 13 Jun 2017 17:29:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=our X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 13 Jun 2017 17:29:18 +0000 Received: by simark.ca (Postfix, from userid 33) id 7C72D1E4E8; Tue, 13 Jun 2017 13:29:21 -0400 (EDT) To: Eli Zaretskii Subject: Re: [PATCH] Fix python compatibility with old versions of GDB X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 13 Jun 2017 17:29:00 -0000 From: Simon Marchi Cc: Tom Tromey , orgads@gmail.com, gdb-patches@sourceware.org In-Reply-To: <83ink03q1w.fsf@gnu.org> References: <227db26304444bfb5ed8f699ab67e7fd@polymtl.ca> <87o9tsozn6.fsf@pokyo> <83ink03q1w.fsf@gnu.org> Message-ID: <27c866069cdcc4dc4b5e3cf5d3affe83@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.5 X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg00396.txt.bz2 On 2017-06-13 16:44, Eli Zaretskii wrote: > FWIW, I always configure GDB to use a version-specific data-directory, > because I leave old GDB versions (renamed) on my system, so I could > still use them after installing a new version. E.g., if the new > version turns out to have a bug. I would actually be happier if we > changed our installation scripts to do that by default, because the > scripts are almost never backward-compatible IME. Can you give more details on what you think could/should be done by default? For such a use case, I would compile each gdb with a separate prefix (e.g. --prefix=/opt/gdb/), which would give each install its own data directory. So from my point of view, the "feature" is pretty well-covered.