Re: [anjuta-devel] Code assistance plugin

[Sébastien Granjoux <seb sfo free fr>]

Hi,


Le 28/04/2012 10:55, Johannes Schmid a écrit :
> > * It seems to make more sens to write a new clang plugin for anjuta,
> > oriented on gedit plugin. After this work we can maybe merge the two
> > plugins.
> Why do you think that, please give explanations. I think it is worth
> considering to create a common part for both plugins.

It looks a bit difficult to use a common part in both plugins.

The part using clang is about 40% of the gedit plugin code, it's quite 
small, less than 2000 lines. Most of this code is used to get back the 
argument of the C compiler using a dump of the make database.

Within Anjuta, we can get these information from the project manager 
directly or if we still use the make database, we need to get at least 
the build directory.

Moreover the backend is using directly GEdit or a common part named 
libgcp (the remaining of the code) to display informations. It will be 
interesting to reuse this part too, but we have to rewrite it using 
interfaces and it changes the architecture of language support in Anjuta.


One thing, that could easily be done is to write a GObject wrapper 
around the clang library but I'm not sure it's very useful.



> I still assume we need some kind of database as we cannot compile all
> source code just to search for symbols etc. Also consider that we must
> keep symbols of installed libraries around.

I think keeping a database is useful too but the Gedit plugin doesn't 
have it.

The Gedit plugin is working like the python language support plugin in 
Anjuta, calling the parser each time it is needed without using the 
symbol-db plugin. I think the Gedit plugin is better because it has 
define a common part (libgcp) used by at least the C and the python 
backend. While our python language support plugin has a copy of several 
part of the C language support plugin.


> As time is limited I would first focus on these, while the last two are
> basically available in symbol-db and it is just the point of pushing the
> data to the database.

Yes, but there is no way to do it currently. Moreover currently it's the 
database that is calling the parser to fill itself. Should we keep this 
architecture and still have the database calling a plugin using clang? 
or rather have a clang plugin listing all sources files and filling the 
database?


Best Regards,

Sébastien