Re: [cdt-dev] API for external tools

["Alain Magloire" <alain@xxxxxxx>]

Bonjour

> There have been a few informal discussions about  how external tool
> providers should communicate with the base CDT.   We need discuss these API
> issues here so that all interested parties can contribute to the
> requirements and designs.
> 
> External tool providers might want to be able to do various things as
> consumers, suppliers, controllers or some combination of the three.
> 
> Examples of things
>       ...consumers might want to do:
>           -get at parse information for use in some external tool


I can see a few levels, depending on the granularity of the parsing:
- function level
- AST level(down to statements)
- indexing and invocation, caller

>      ...suppliers might want to do:
>           -contribute an alternative parser to the CDT
>           -extend an existing CDT tool to provide richer functionality
>           -provide actions to act against CDT resources and artifacts
> 
>      ...controllers might want to do:
>           -explicitly control the build
>           -explicitly control a debug session
> 
> There are already a few mechanisms in place that 3rd parties can use to
> communicate with the CDT:
>      1) Eclipse Action Contributions
>           -to provide object actions against resources (we support this for
> local but not remote projects)
>           -we still need to provide this kind of support for working
> against C artifacts
>      2) Miners and the DataStore Framework
>           -to get remoteable (works remotely as well as locally)
> integration with the core tools and the UI
>           -miner contributions automatically sufaced by views
>           -we still need to provide better way to allow 3rd parties
> configure which miners get loaded
>      3) some APIs
>           -there are some UI APIs that let you do some basic things, but
> they aren't really designed for external use
>           -there are also ways to integrate with the DataStore Framework
> from the UI side
> 
> Now we need to know what's missing.   In particular, we need to provide
> functionality that meets the requirements of external providers, where
> reasonable.   There are a lot of questions that this raises.  To name a
> few:
>      -What do 3rd parties want to be able to use CDT for?
>      -In what form should output from consumer APIs be?
>      -How are providers' tools used with other non-CDT technologies?
>      -Where are the primary tooling interests of the 3rd parties?  Local,
> remote or both?
>      -What are the practical ways to categorize and organize APIs?


Inspection, for example an Editor that wants to provide tag navigation

For example in our case we have profiler, trace etc .. plugins.  The target
is sending back quite a lot of information, for example for the profiler
function arcs, that we should be able to find and link to the editor.
The same goes for trace.  In essence what we do now.

Same goes for the debugger and the build.  For example GDB is just
a default implementation.

> In this thread, I hope we can generate some good discussion and maybe
> answer some questions.  It is critical that we hear from 3rd parties,
> themselves, but it would be nice to hear from other interested parties as
> well.
> 
> ____________________________________
> David McKnight
> Linux AD, CDT Development
> Phone:   905-413-3902 , T/L:  969-3902
> Internet: dmcknigh@xxxxxxxxxx
> Mail:       D2/ 329/8200/TOR
> ____________________________________
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
> 


-- 
au revoir, alain
----
Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!