Re: Sharing code between Nemiver and Anjuta



Hi,


I have get Nemiver, compiled it and started to read the code. I describe below my first view of Nemiver code. It includes my own opinion, so please correct me if I have misunderstood something or if you disagree.



The architecture is very similar to Anjuta. There is a main function which is loading plugins (DynamicModule for Nemiver) which are responsible for providing the functions. There is a common library which is named libnemivercommon instead of libanjuta. Like in Anjuta, the debugger is splitted in two modules: one responsible for the GUI and one which wraps gdb (libgdbmod).

The main difference is that Nemiver is written in C++ and is using its own types while Anjuta is using GLib. By example there is a nemiver::Object which is a very simple version of GObject or DynModIface which is replacing GInterface.

Nemiver is using GLib and Gtk, by example, GModule for loading its module but it's completely hidden at the lowest level. So it cannot be used as a GLib library. I think that GObject introspection is not working on Nemiver libraries, by example.



* I think we can try to use the gdb module (libgdbmod) of Nemiver. I think it's a bit better than Anjuta gdb plugin but the main advantage is that the interface is well defined. We need a wrapper to convert GObject into Nemiver object and the opposite though. Is there someone interested to work on it on Nemiver side?

I suppose this wrapper could be generated more or less automatically by some scripts like it is done for GObject C++ bindings.

At the beginning, I have imagined that we could use the GObject C++ bindings but I think it will not work because Nemiver uses its own classes.

Do you see another solution?



* Nemiver is split in quite a lots of libraries, by example the parsing of gdb output is compiled in a separated library. It is possible to use them but again the issue is that there are written in C++. I think writing a wrapper is less interesting for such smaller libraries unless it can be generated automatically.



* Another possibility is to do it in the opposite way, I mean write something in C using GObject and use it in Nemiver. In this direction, the wrapper can be generated more or less automatically. Is there some parts of Anjuta that would be useful for Nemiver? Or do you have ideas of something those can be written in C and used by both programs?



* If we continue the previous idea at its limit, we can wrap all Anjuta plugins to use them in Nemiver and transform Nemiver in a full IDE. I add this as a possibility but I don't think it worths it. What do you think?



* Finally, the last remaining usage of Nemiver code could be just to read it and see what can be learned from it and re-implement it in Anjuta. The function of both programs overlaps and the architecture is quite similar so we have faced the same issues.


Regards,

Sébastien


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]