Sorry for not replying earlier to this thread, I hope I can still provide some useful insights. Please forgive me if I repeat some things already said, I've not read the whole thread in great detail. I will first give some comments on the questions you listed here (I know they are already discussed later in the thread, but I just want to give my opinion/insight).
2012/4/22 Sébastien Granjoux
<seb sfo free fr>
Hello Jesse,
We are interested to use clang in Anjuta to provide error reporting, perhaps improve auto completion and other things.
I have looked at your gedit plugin to see which parts can be shared. As far as I understand, your code is divided in 3 plugins at the moment:
- A common part named gcp interfacing with GEdit
Yes and no. It's true that currently gcp contains the binding with gedit. But it also contains an infrastructure which is used to implement the backends, which is mostly (but not completely) independent from gedit.
- A backend for python.
- A backend for C using clang.
Yes. The idea here is that we can develop support for different languages separately. There are a set of interfaces defined in gcp that the backends (and backend documents) can choose to implement. gcp then checks which interfaces a backend implements and glues the corresponding functionality into gedit. If you are interested a bit more in how this works, then you can have a look at the gcp-c-document.vala which implements various interfaces for symbols, diagnostics and semantic values (which are basicly things like functions, classes, variables and their references).
Anjuta doesn't use libpeas for plugins. Moreover plugins don't have a direct access to GtkSourceView object but have to use an interface. So we cannot use these plugins directly without some important changes in Anjuta and GEdit.
Yes, and that is a shame! You should consider using libpeas :) I've seen some posts about sharing plugins between gedit and anjuta, and I don't think it's a good idea. Introducing another level of abstraction just to make it compatible is not going to be interesting for either Anjuta or gedit. The way we try to manage this a bit is by slowly merging functionality that was developed as a plugin (because it's just much faster) in a library (most notably gtksourceview). This library can then be easily reused, given it exposes the proper API.
But I think it could be possible to write a GObject wrapper around clang library and share this library in both Anjuta and GEdit C backend plugin. Do you think it's useful? Do you have ideas to share more code?
I think this might be interesting, but also problematic in some ways. Both gedit and Anjuta currently create abstractions (interfaces) to abstract away some of the specifics of different languages. I did that in gcp using the various interfaces there. I'm really not familiar with the Anjuta code base (sorry for that), but I imagine you do something similar. The problem is now what to do with this GObject library:
1) Make it a very shallow wrapper around libclang. This can be done, but is it really interesting to do? If you use vala you can simply use the .vapi file that I wrote and you can access all the libclang API in an object oriented way from vala, no GObject needed. Also, there wouldn't be any code sharing really, the shallow bindings would not be where most of the work is done.
2) Make a common abstraction layer for these kind of compiler services which can be reused by multiple projects. This is much more interesting in the end, but also much more difficult to do. I think it will be difficult (but not impossible) to merge the ideas from Anjuta and from gcp into a library providing a standard API/interfaces for building and using language assistance. These interfaces should then be used by both projects. Ideally, neither project would have their own abstraction layer on top of this library because abstractions of abstractions == bad. I know Anjuta kind of likes this (i.e. having support for both Scintilla and GtkSourceView), but I really, really strongly feel this is the wrong way to go (do you like wxWidgets?) .
I know that we both have our own ideas, and having a common API will make things harder, because we have to agree on things, and we often might not have the same use cases, but it should be possible.
That said, maybe some other general comments
1) I read about rewriting parts of the gcp plugin to C, this is a _bad_ idea. Use vala, really. It's not really worth it anymore to write these kinds of things in C, the boilerplate is mindboggling. vala will compile nicely to GObject C, you can generate a .gir for you lib and generate a gi typelib, then use your vala library from any introspection supported language.
2) Don't shun from thinking about collaborating on this. I know how this normally goes (I do this myself), it's much easier to just write a little plugin using clang to use just for Anjuta. But in the end we'll be maintaining two things separately. Now is the time to think about how to provide general compiler services for GNOME applications. Having a common library we could even think about writing dbus services to organize things globally at some point.
3) I saw some ideas of merging the gedit and Anjuta applications. This I think will not really be possible, if only for the reason that we (gedit) would like to merge anjuta functions into gedit, and anjuta would like to have it the other way :) Like I said before, the way I see sharing of code is in the way we do that with GtkSourceView.
4) I've noticed some performance and memory issues with using libclang. There are also some bugs related to the AST which I haven't yet resolved, but seem to be related to macro's (maybe newer version of clang will have it fixed). It might be worth to either contribute to libclang directly, or to make our own library that uses the lower level C++ API's.
Regards,
Sébastien
