This is the mail archive of the gdb@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: Bob's MI objective


On Fri, Oct 08, 2004 at 08:56:19AM +0200, Fabian Cenedese wrote:
> 
> >> >Understood, here is what I am hoping for at a minimum. 
> >> >
> >> >   * GDB supports at least 1 MI protocol for an official release. 
> >> >     Supporting multiple MI protocols would be better for me, but 
> >> >     not a requirement. If GDB could support multiple protocols it 
> >> >     would improve the chances of a given front end working with a
> >> >     given GDB.
> >> 
> >> But by "support" what do you mean - even a dictionary definition.  GDB 
> >> includes at least one MI implementation, but that says nothing about how 
> >> well it is either implemented or supported.
> >
> >That's a good question.
> >
> >Well, by support I simply mean, GDB is officially saying that a
> >particular MI protocol is implemented as it should be, that it is tested
> >to make sure that it works to the best of the GDB developers knowledge and 
> >that it is safe to use by front ends.
> >
> >I am assuming that MI protocols in development ( right after a version
> >bump, but before a major release ) is considered unsupported. By this I
> >guess I mean that it should not be used by front ends until it is
> >stable. Maybe a better word for "support" in this context is "stable".
> 
> I think the implementation grade is quite important. Though mi2 is
> considered now the official and stable mi version I find that half of it
> is unimplemented which makes it somehow useless for me. From
> this point of view I'd say mi2 is the development version.
> (And yes, I'm not only complaining, I have started implementing some
> of the missing mi functions.)

Yes, I understand what you mean here, however, it is a slightly
different problem.

I am strictly calling an MI protocol a "development version of MI" if
the MI output syntax has not been nailed down ( I've got the hammer )
for an official release. I know there are other reasons why a version of
MI could be under development, I am just picking on this one case.

I've already described the problem were GDB is released with a stable MI
protocol. Then development begins for the next release. A backwards
incompatibility happens and the MI version is bumped and the MI output 
syntax changes. Before the next release another incompatible change can
occur and the MI output syntax could change again without a version
bump. For this reason, a front end could never communicate with all of
these MI protocols ( different grammars ), until a release has been made
and the protocol syntax is stable.

Even though I might be asking hypothetical questions, I was trying to
determine what things would cause the MI protocol to get bumped, so we
could figure out what constitutes a development version and what is a
stable version.

This is why I asked if adding new functions bumps the version, however,
several people suggested it shouldn't.

Thanks,
Bob Rossi


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