From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22580 invoked by alias); 26 Feb 2008 02:31:39 -0000 Received: (qmail 22571 invoked by uid 22791); 26 Feb 2008 02:31:39 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 26 Feb 2008 02:31:02 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 7F99998118; Tue, 26 Feb 2008 02:31:00 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 28AC19801D; Tue, 26 Feb 2008 02:31:00 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JTpat-0002I4-Dh; Mon, 25 Feb 2008 21:30:59 -0500 Date: Tue, 26 Feb 2008 02:34:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Doug Evans , Vladimir Prus , gdb-patches@sources.redhat.com Subject: Re: [RFC] Variable objects for STL containers Message-ID: <20080226023059.GC4456@caradoc.them.org> Mail-Followup-To: Nick Roberts , Doug Evans , Vladimir Prus , gdb-patches@sources.redhat.com References: <18354.25849.317151.537741@kahikatea.snap.net.nz> <18360.38522.477967.328610@kahikatea.snap.net.nz> <18360.46269.11283.751538@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18360.46269.11283.751538@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.17 (2007-12-11) 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: 2008-02/txt/msg00381.txt.bz2 On Mon, Feb 18, 2008 at 11:27:08AM +1300, Nick Roberts wrote: > This is not any STL, but Gcc's STL. Gdb and Gcc are both part of the GNU > project so should possibly have a special relationship. I agree, but I don't think this is the way to do it. I've found that the easier we make it to hack on this sort of thing (in this case, support for custom display of objects), the more likely we are to get people who are experienced in the right areas to help out. Suppose we support this as a bunch of text scripts, ignoring what language they're written in. Then they can ship with GDB for old versions of GCC but transition to shipping with GCC for new versions of libstdc++; and I think the libstdc++ maintainers will be happy to improve them and keep them up to date. > I don't really understand how the python support will be implemented but I > don't see why variable objects for STL containers should require Python > libraries to be present. Script engines are just tools. If we want to use tools, I think it's OK to have a dependence on them. For practical reasons, I believe we should use generally portable tools and (for now, at least) support building a functional GDB without them; that's the decision we made for expat. -- Daniel Jacobowitz CodeSourcery