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

[Massimo Cora' <maxcvs email it>]

hi,

On 12/13/2010 11:23 PM, Johannes Schmid wrote:
> Hi!
>
> > well, we can act as `dpkg -S` does on debian: we could query
> > project-manager and ask it to which package it belongs to.
> > I suppose that using the meta-packages and the libraries packages, there
> > will be really few headers left alone.
> > If that's the case we can put those orphans under a 'unknown' package.
> > Doing this separation will help the db at query time.
>
> Sorry, I still don't get how that would help query time in any way.

with a simple sql join you can have all the files and symbols included 
in a package. That join is really fast because it would use indexes and 
other db optimizations. Ideally those includes are also connected each 
other [recursive levels of includes, as Naba says] and you won't risk to 
include <string.h> and not find a function which is mandatory for 
<string.h> to work and that isn't directly included by user. Ok, this 
<string.h> is probably not the best case, but I'm sure that the problem 
is somewhere else.
Leaving the files separated and without a sql constraint would force us 
to use
1. long files lists to filter between all scanned files [in a single db]
2. create and maintain temporary dbs where to scan and save the headers.

I'm not totally against global temp-dbs, but are we sure that rescanning 
only one level of includes is enough to have a decent completion?

Different is the thing where the user opens files of other projects or 
files that aren't in any way connected with the ones of the opened 
project. In that case a memory db is the only way. The scan would be 
quick and mostly of the times won't be reusable.

> Simple example to make this clear:
>
> #include<string.h>
>
> So, we would know that string.h is part of glibc (in case we would
> create such a virtual package). But we don't want to search in whole
> glibc because the user only included string.h and not stdlib.h or
> file.h. As such we totally don't care which package the file was in.
>
> I am not against putting the package name in the db somewhere but I just
> don't see a huge benefit in having it when we search file-based.


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?

regards,
Massimo