Re: probing GDB for MI versions

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Fri, 15 Oct 2004 11:40:17 -0400
> From: 'Bob Rossi' <bob@brasko.net>
> Cc: gdb@sources.redhat.com
> 
> I think that supported(tested) and unsupported(untested) are two
> entirely different things.

Not entirely: an MI version does not become buggy just because you
stop testing it.  The bit-rotting process takes time, and during that
time the untested MI is still working reasonably well.

Also, the fact that something is tested does not mean there are no
bugs in it.

So let's stop talking about absolutes because they are not appropriate
here.  Let's keep the discussion focused on practical problems, not on
principles.

> > > It would be
> > > nice if the front end was capable of understanding that.
> > 
> > And then do what? print a message "like unsupported GDB version"?  Is
> > this really an interesting case?  
> 
> I consider this a very interesting case.

More interesting than the case where the front end _can_ find a
working MI version?

> I don't want a reasonably well working verion, I want a version that
> it tested in the testsuite.

Then you must make sure your front end supports the latest stable
version, and only that version, and this whole discussion is mostly
irrelevant, because just printing the latest stable version is all you
need (if the front end doesn't support that version, it should refuse
to work).  See below.

> * printing just the latest stable version
> 
>    Is this the version that GDB will start up in if you do -i=mi even if
>    you are using a CVS snapshot and the version has been bumped?

No.  The latest stable version is not the one that is invoked with
"-i=mi", it is the stable version before that.

>    This solution is lacking. It only tells the front end the latest
>    stable version of the MI protocol. The front end can only guess what
>    other stable versions are available and I consider this unacceptable.

According to what Andrew said, and since you don't want to use
untested old versions, the latest stable version is all you need.

>    However, this solution requires starting GDB twice, which I would not
>    prefer if it was solvable with just starting it once.

I don't see any problem in restart, if that is indeed required.
However, it sounds like a restart will not be needed, since the front
end supports only one version: the latest stable one.

Again, if you are unprepared to work with any MI version but the ones
that are actively tested by the testsuite, then your front end will
need constant work to make it support the latest stable version, and
it should refuse to work with any other version.