Re: [anjuta-devel] RFC: Symbol-db future

[Massimo Cora' <maxcvs email it>]

On 12/14/2010 12:48 AM, Johannes Schmid wrote:
> Hi!
>
> > we would need some real cases where the method works and where not.
> > You mentioned<gtk.h>. In that case, stopping the scanning at the first
> > level, you won't get anything useful to completion.
> > We may set a trade-off of two or three levels at most. Would it be
> > sufficient?
>
> Actually I was thinking about infinite levels (=>  scan all files
> included) because that is exactly what "gcc -MM filename" gives us. I
> think any limitation in level would make things not work for some
> people.

yes, well, best would be to take the most of the people. Special cases 
can be left behind. You cannot always meet everyone's needs.

> For me the main question is if we can do a query on the global database
> (containing all header files we ever visited) that only gives us the
> symbols of the files we want and how fast this query is. If it isn't
> fast enough we might think of creating a temporary database that will
> speed up subsequent queries.

we may create temporary packages that grow up with the included files. 
The files belonging to temporary packages may also be part of 'normal' 
packages, so that no hard-dependence is made.
This would require some changes on db logic but it's feasible without 
too much work. The packages will then represent meta group of files. We 
can save the temporary ones on project session, and load them at 
project-load time. They can be saves as hashes so that they'll be unique.
What do you say?

> IMHO doing the search based on packages would be a nice step forward but
> I feel that we might want to drop the intermediate think and do the real
> solution now.
>
> Just want to make clear that I want to hear everybody's opinion and that
> I would like to do a decision together based on the best arguments.

sure that's fine.



regards,
Massimo