Re: SourceNav release ...

[Mo DeJong <supermo@bayarea.net>]

On Thu, 10 Jan 2002 03:23:33 +0200
"Eray Ozkural (exa)" <erayo@cs.bilkent.edu.tr> wrote:

> I have an important question to ask. For the past two weeks or so we have 
> been discussing how the parser backend should be in KDevelop IDE. As a 
> computer scientist, I feel what the Right Thing (TM) is but as far as 
> practically goes it is out of question [*].
> 
> What we have here is a class store API (which is basically a tree structure) 
> that is intended to provide type information for class based languages. 
> KDevelop hackers are retro-fitting a C++ parser for doing things like code 
> completion.
> 
> However, my hunch is that it will not be a general purpose or complete 
> solution to the problem.

You are correct, that is not a complete solution. You can't just hack a compiler to generate symbols for your project. That works when the code is perfectly correct but it will explode on code that does not compile. You first reaction might be, "duh, of course the code needs to compile". Thing is, users need the tool to work even if the code does not compile. This fuzzy parsing functionality is not a feature you can tack on later. It needs to be part of the original parser design.

> The next best thing that comes to my mind is sourcenav for three reasons. It 
> has solved the multiple languages & persistence problems reasonably well.
> And, it's very portable. Would you deem merit in trying to re-use code from 
> source navigator in a C++ code base? (ie we would be using the C API of 
> sourcenav). What advantages/disadvantages of sourcenav parser/type analysis 
> backend would you think of as the sourcenav maintainer? And how should one go 
> about it? (can the whole back end be made into a library?)

I think the right solution is to turn the SN backend into a library. Even if you don't reuse the code, the ideas that are there have years of effort behind them and they do work. It should make use of Berkeley DB to store symbols but through an API so that people can swap out other database layers if they want to. It should also provide a nice two phase parse and dump into symbol DB sequence that is easily inspected. Just figuring out what and where the problem with a parser is can be the most difficult part of fixing a problem. Also, it is absolutely critical that a well defined regression test framework is developed as part of the library.

Of course, the tricky part is how to move forward. If you just make a KDE version of Source-Navigator then it will only be useful to KDE folk. There are plenty of other development tools that could really make use of this functionality if it was available in an well documented and easy to use library format. The larger the user base, the more bugs will get worked out. User base is important since parsers are so bug prone. This project is something I was thinking about working on, but it is quite a bit of work and will require more than one developer.

cheers
Mo