From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95775 invoked by alias); 17 Jul 2018 12:23:53 -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 95760 invoked by uid 89); 17 Jul 2018 12:23:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1608, widget X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jul 2018 12:23:46 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D319540122B3; Tue, 17 Jul 2018 12:23:44 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 45B112026D68; Tue, 17 Jul 2018 12:23:44 +0000 (UTC) Subject: Re: [RFA] Remove --disable-gdbcli and --disable-gdbmi To: Tom Tromey , gdb-patches@sourceware.org References: <20180628172132.28843-1-tom@tromey.com> From: Pedro Alves Message-ID: <8bebd1b1-e620-b393-bc0d-d216ca737327@redhat.com> Date: Tue, 17 Jul 2018 12:23:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180628172132.28843-1-tom@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-07/txt/msg00507.txt.bz2 On 06/28/2018 06:21 PM, Tom Tromey wrote: > I think it doesn't really make sense to allow building gdb without the > CLI or without MI. Perhaps at one time this was a goal, but libgdb is > long gone, the CLI is intrinsic to gdb, and MI is relied on by many > GUIs. > > So, this patch removes the implementation of these configure options. > They are still recognized (this is autoconf's default), but do > nothing. > > This simplifies configure.ac and Makefile.in a bit. > > Tested by rebuilding. I think it's safe to say that most MI frontends end up relying on CLI commands, e.g., because they allow setting breakpoint commands or expose a command line widget, or because of gdb/Python scripts. While it's conceivable that someone might want to drive gdb via MI for some targeted use case that does not rely or want a CLI might make sense, it seems unlikely to me. In any case, --disable-gdbcli doesn't really work, so nobody is going to miss it. OTOH, wanting to disable the MI seems a bit more likely, at least plausible. Doing a web search for "--disable-gdbmi" finds , someone doing just that. That was 10 years ago, and there doesn't seem to be many more examples though, at least in the public. It doesn't look like removing --disable-gdbmi simplifies that much, so I'd be inclined to keep it, since it actually works. Do you have further plans of simplifications in this area that this patch would enable, or was this just something you happened to run into? Thanks, Pedro Alves