From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30095 invoked by alias); 1 Oct 2002 00:48:54 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30088 invoked from network); 1 Oct 2002 00:48:53 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 1 Oct 2002 00:48:53 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g910mq910849 for ; Mon, 30 Sep 2002 17:48:53 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 30 Sep 2002 17:48:52 -0700 Received: from apple.com (vpn-scv-x2-210.apple.com [17.219.193.210]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g910mpV26848 for ; Mon, 30 Sep 2002 17:48:51 -0700 (PDT) Date: Mon, 30 Sep 2002 17:48:00 -0000 Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Jim Ingham To: gdb-patches@sources.redhat.com Content-Transfer-Encoding: 7bit In-Reply-To: <1033404264.17743.ezmlm@sources.redhat.com> Message-Id: <8D22C792-D4D7-11D6-A585-000A277A8808@apple.com> X-SW-Source: 2002-09/txt/msg00790.txt.bz2 Hi, all... The changes from mi0 to mi1 were pretty trivial. So clients (in my case Project Builder) can fairly easily accommodate the removal of the mi0 interpreter. I am not suggesting that we reinstate that. However, the mi2 is shaping up to be a pretty big change (among other things, command results are differently reported in toto, as well as some command results changing format.) Converting PB from mi1 to mi2 is going to be a lot of work. And because of its nature, there is no a priori way to tell what all the clients are - and not all the clients will closely read the gdb-patches mailing list... Because of this, I am a little nervous at the easy way we are talking about deleting older versions of the mi. I think it is our responsibility to careful, and only release versions of the mi that we want to support, not the clients of the mi's responsibility to change their code every time we decide we are tired of supporting the test cases from one of the other versions we have previously promulgated... The mi loses much of its appeal if it means you are going to have to occasionally rework parts of your client that already work just fine, or suffer permanent fork-hood for your gdb. I agree with Daniel that we should hold off on declaring a real mi2 till we have something we are willing to support long term. And for the mi to be useful, I think we need to stick to only putting out named versions that we are willing to support. Jim > On Mon, Sep 30, 2002 at 11:03:55AM -0400, Andrew Cagney wrote: >> >>>>> >>>>> Are you planning to revert mi1 then? >>> >>>> >>>> Que? >>> >>> >>> "mi2" changes have been sneaking in. Are you planning to revert >>> them - >>> create an "mi1" which matches what mi1 actually was. >> >> It's a bit late for that. Someone should audit the changes made so >> far >> and identify which caused syntax changes and update accordingly. >> Fixes >> could, perhaphs be pushed into 5.3 (but I don't have the time). >> >>> Otherwise, where is the line drawn to mark the interface version as >>> final? It seems to me that the default shouldn't be evolving, that >>> -i=mi should default to a fixed point until the next version is >>> running. >> >> I think a line is drawn when each release is made. I'd expect an MI >> client to explicitly specify -i=miN (where N was formally released) >> rather than trust -i=mi. >> >> However, should the HEAD hold off on recognizing -i=mi2 until the next >> branch is cut? On the HEAD, -i=mi evolves by definition. However, >> -i=mi2 is evolving as well :-( > > That'd be best I think. I think that -i=mi2 specifies a fixed standard > and we don't have one yet; so how about -i=mi being different from > -i=mi1, but not adding -i=mi2 until we're ready to fix the interface? > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer > _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Jim Ingham jingham@apple.com Developer Tools - gdb