Re: MI level command

["Alain Magloire" <alain at qnx dot com>]

> 
> On Thu, Jul 08, 2004 at 07:33:17PM -0400, Alain Magloire wrote:
> > Yellow
> > 
> > 
> > Scenario:  We want to know wich level of MI that we are currently working in.
> >   This can allow to adjust what MI command to use and how to parse them.
> > 
> > Problems: No such command in MI and no GDB variable that we can test via -gdb-show.
> >   The version of  gdb
> >      gdb --version
> >   show different things in different distributions, sometimes it is a number based on date
> >   etc ...
> > 
> > So would a patch implementing
> > 
> >  -gdb-mi-level
> >  ^done,level=1
> > 
> > be a good thing ?
> 
> I like this idea a lot. I will need it when I start getting more work
> done on TGDB. However, there is another DRY problem. What functions act
> which way for which level?
> 

Agreed, it is a problem, I do not have any solutions.  For example
say thread-list-ids been crashing or misbehaved and the latest gdb fix the
problems ... For front-ends how to know this is fix ?

In theory the combination of version and the MI level should have done the trick.


> Basically, should every front end understand that
> -file-list-exec-source-files outputs just the files for level 1 but it
> also outputs the libraries the files belong to in level2?
> 
> One solution could be, for every MI function, we could generate a unique
> key. For example, mi1-file-list-exec-source-files,
> mi2-file-list-exec-source-files, ...
> This key would tell the front end to use that particular parsing
> function when checking the output of -file-list-exec-source-files.
> 
> Is this to wacky?
> 

It sounds like a lot of maintainance.
How about for every release of gdb we bumb up a number ?
Say MI level could return {0,1,2,..} and MI gdb version could return something else.
So the unique key is for a release and all commands ... basically having taking the role of version.

So why is "version" so mangle in gdb ?