This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]