From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19315 invoked by alias); 5 Dec 2014 09:54:07 -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 19299 invoked by uid 89); 5 Dec 2014 09:54:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 05 Dec 2014 09:54:04 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sB59s0MK029597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Dec 2014 04:54:00 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sB59rwFE011807; Fri, 5 Dec 2014 04:53:58 -0500 Message-ID: <548180B5.4060003@redhat.com> Date: Fri, 05 Dec 2014 09:54:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Don't enable gdbtk in testsuite References: <1416903049-30419-1-git-send-email-yao@codesourcery.com> <548094B1.8050708@redhat.com> <87y4qmd1qu.fsf@codesourcery.com> In-Reply-To: <87y4qmd1qu.fsf@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-12/txt/msg00123.txt.bz2 On 12/05/2014 06:55 AM, Yao Qi wrote: > Pedro Alves writes: > >> That patch removed it from the git repo, mirroring how CVS modules >> worked. In CVS, if you checkout the "gdb" module, you don't get >> the gdbtk dirs, but if you checkout the insight module instead, you >> get everything gdb, plus the insight bits: src/gdb/gdbtk subdir, >> src/gdb/testsuite/gdb.gdbtk/, and maybe other bits. > > Hi Pedro, > I looked at insight and the date of the last commit in > gdb/testsuite/ChangeLog is 2013-10-21. Looks insight stops updating gdb > after gdb migrates to git so I think it should be safe to remove > testsuite gdbtk from gdb head. insight's official repo is kind of stuck in a limbo. CVS is dead, so that's not where you should be looking. There's no official git repo yet, but AIUI, people are using this non-official repo instead: https://github.com/monnerat/insight In any case, I don't see why we should treat insight bits in gdb/testsuite/configure.ac any different from bits in gdb/configure.ac. It's exactly the same issue. >> So removing the testsuite support for gdbtk doesn't seem like >> the right thing to do. Particularly since we still have the >> gdbtk bits in gdb/configure.ac. IOW, I don't see how >> src/gdb/testsuite/gdb.gdbtk/ not being around is different >> from src/gdb/gdbtk/ not being around. We should either keep >> all support for gdbtk, or remove all of it. > > It is aggressive to remove gdbtk bits from gdb/configure.ac, although > there were some "insight end-of-life" discussions on insight mail list. That topic was raised, but from those discussions it seemed clear to me that there is still interest in it. E.g., https://sourceware.org/ml/insight/2014-q4/msg00007.html https://sourceware.org/ml/insight/2014-q3/msg00010.html Personally, I wouldn't be adverse to importing gdbtk into the official gdb repo. I don't see how that could hurt -- we tend to worry about insight anyway when we touch code that might affect it, like most the deprecated_foo hooks. > I am OK to revert my patch. I think we should do that. Thanks, Pedro Alves