|
From: Naba K. <kh...@gm...> - 2005-05-03 13:28:18
|
Hi Nicholas, On Tue, 2005-05-03 at 18:00, Nicholas Nethercote wrote: > > 3) API interface: This is the best and most preferred way for > > the integration. In this case, valgrind offers a library that > > an Anjuta plugin proxies to the IDE's internal interfaces. > > Out of interest, what does the API look like? Do you have a webpage > describing it? > I think you misunderstood me. I was suggesting to have a library in valgrind (e.g libvalgrind or something) that will give the necessary API to IDE developers. The reason why I believe it's a better solution than parsing CLI output is that it is easier to track and manage API changes in a library than CLI format changes. Maintaining a parser of valgrind output, that could change arbitrarily, is surely not going to be easier. > > In case(2) and case(3), the integration requires developing > > an Anjuta plugin, but that is the least difficult part since > > it will hardly span more than one source file. > > Yes. And unless a very general mechanism (such as the "displayer" module) > can be implemented in Valgrind, I think this is the right way to do it: > have extra code in Anjuta to deal with Valgrind, rather than extra code in > Valgrind to deal with Anjuta. > The suggested code in valgrind is not to deal with Anjuta, but to have an easy way for any IDE to deal with valgrind. The anjuta-plugin thing I said was for Anjuta and not for valgrind. I was just highlighting the point that if valgrind offers such a library, many IDEs will find it much easier to implement their plugins. It was also a comment for someone interested to write such a plugin for Anjuta (reference to a previous message in the thread). The "displayer" thing you suggested is a nice approach. I hope we it is implemented soon. Thanks. Regards, -Naba |