MI fine-grained versioning

MI fine-grained versioning

[Vladimir Prus]

At the moment, MI does not have any mechanism to announce supported
features. For example, I have a patch to add "frozen" variable objects. To support
such feature in a backward-compatible fashion, the frontend must know if that
features is supported by the given gdb binary.

Using version number is not very reliable -- for example if you use the CVS state
of gdb, the version number is not yet bumped.

Yet another approach is to "detect" presence of feature by trying some commands,
or by trying commands with some new options, or by constructing more contrived test
cases. However that's troublesome.

How about adding new MI command that returnes list of supported fine-grained features.
For example:

	-list-features
	^done,result=["frozen_variables","info_path_expression"]

The MI manual would contain a section listing all feature names and briefly documenting them.

Comments?

- Volodya

Re: MI fine-grained versioning

[Bob Rossi]

On Mon, Dec 18, 2006 at 06:35:33PM +0300, Vladimir Prus wrote:
> 
> At the moment, MI does not have any mechanism to announce supported
> features. For example, I have a patch to add "frozen" variable objects. To support
> such feature in a backward-compatible fashion, the frontend must know if that
> features is supported by the given gdb binary.
> 
> Using version number is not very reliable -- for example if you use the CVS state
> of gdb, the version number is not yet bumped.
> 
> Yet another approach is to "detect" presence of feature by trying some commands,
> or by trying commands with some new options, or by constructing more contrived test
> cases. However that's troublesome.
> 
> How about adding new MI command that returnes list of supported fine-grained features.
> For example:
> 
> 	-list-features
> 	^done,result=["frozen_variables","info_path_expression"]
> 
> The MI manual would contain a section listing all feature names and briefly documenting them.

Great idea!

There are a few gothcha's. For instance, each command can support
several parameters, so you might want to report on that. But more
tricky, is when a command adds an output field that the front end cares
about. An example of this would be that the -break-list command has
always existed, but the -break-list command added fullpath functionality
later on it it's life. How would you handle this, if at all?

Thanks,
Bob Rossi

Re: MI fine-grained versioning

[Daniel Jacobowitz]

On Mon, Dec 18, 2006 at 06:35:33PM +0300, Vladimir Prus wrote:
> Yet another approach is to "detect" presence of feature by trying some commands,
> or by trying commands with some new options, or by constructing more contrived test
> cases. However that's troublesome.
> 
> How about adding new MI command that returnes list of supported fine-grained features.
> For example:
> 
> 	-list-features
> 	^done,result=["frozen_variables","info_path_expression"]
> 
> The MI manual would contain a section listing all feature names and briefly documenting them.
> 
> Comments?

If you want to do this, it sounds like this is the right way - compare
to the qSupported I recently added for the remote protocol.  I guess
this is the logical place to add a list of supported MI versions,
too...

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI fine-grained versioning

[Vladimir Prus]

On Monday 18 December 2006 18:39, Bob Rossi wrote:
> On Mon, Dec 18, 2006 at 06:35:33PM +0300, Vladimir Prus wrote:
> > 
> > At the moment, MI does not have any mechanism to announce supported
> > features. For example, I have a patch to add "frozen" variable objects. To support
> > such feature in a backward-compatible fashion, the frontend must know if that
> > features is supported by the given gdb binary.
> > 
> > Using version number is not very reliable -- for example if you use the CVS state
> > of gdb, the version number is not yet bumped.
> > 
> > Yet another approach is to "detect" presence of feature by trying some commands,
> > or by trying commands with some new options, or by constructing more contrived test
> > cases. However that's troublesome.
> > 
> > How about adding new MI command that returnes list of supported fine-grained features.
> > For example:
> > 
> > 	-list-features
> > 	^done,result=["frozen_variables","info_path_expression"]
> > 
> > The MI manual would contain a section listing all feature names and briefly documenting them.
> 
> Great idea!
> 
> There are a few gothcha's. For instance, each command can support
> several parameters, so you might want to report on that. 

Yes. For example if -var-registers end up being

	-var-create --registers

we'd need a feature name.

> But more 
> tricky, is when a command adds an output field that the front end cares
> about. An example of this would be that the -break-list command has
> always existed, but the -break-list command added fullpath functionality
> later on it it's life. How would you handle this, if at all?

That's actually easy. If a frontend can handle the extra field locally,
then we don't need new element in -list-features. If it cannot, we need new element.
This "can" and "cannot" is determined by hacking the relevant support in KDevelop.
If an author of some other frontend wants new item in -list-features, that element
is added too. It's generally easier  to add new elements to -list-features as frontend
authors request, then argue about "inherent" need to announce a specific change.

- Volodya

Re: MI fine-grained versioning

[Nick Roberts]

 > > How about adding new MI command that returnes list of supported
 > > fine-grained features.  For example:
 > > 
 > > 	-list-features
 > > 	^done,result=["frozen_variables","info_path_expression"]
 > > 
 > > The MI manual would contain a section listing all feature names and
 > > briefly documenting them.
 > 
 > Great idea!
 > 
 > There are a few gothcha's. For instance, each command can support
 > several parameters, so you might want to report on that. But more
 > tricky, is when a command adds an output field that the front end cares
 > about.

In the manual we already explain that front ends should be able to handle
extra fields in MI output.  The front end would need to do this just
to handle -list-features.

 >         An example of this would be that the -break-list command has
 > always existed, but the -break-list command added fullpath functionality
 > later on it it's life. How would you handle this, if at all?

Clearly it can't be retrospective.  I think it's a good idea and would be
more convenient than bumping the level for small changes.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI fine-grained versioning

[Bob Rossi]

On Tue, Dec 19, 2006 at 08:47:35AM +1300, Nick Roberts wrote:
>  > > How about adding new MI command that returnes list of supported
>  > > fine-grained features.  For example:
>  > > 
>  > > 	-list-features
>  > > 	^done,result=["frozen_variables","info_path_expression"]
>  > > 
>  > > The MI manual would contain a section listing all feature names and
>  > > briefly documenting them.
>  > 
>  > Great idea!
>  > 
>  > There are a few gothcha's. For instance, each command can support
>  > several parameters, so you might want to report on that. But more
>  > tricky, is when a command adds an output field that the front end cares
>  > about.
> 
> In the manual we already explain that front ends should be able to handle
> extra fields in MI output.  The front end would need to do this just
> to handle -list-features.

Yes, this should be obvious. I'm suggesting that the front end might
rely on a particular field to be sent from an MI command to consider it
a valid 'version'. Anyways, a good solution to this problem was already
given on the list.

Bob Rossi