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

["Johannes Schmid" <jhs jsschmid de>]

Hi Naba!

> It can easily be just a query on the main DB with additional condition
> to filter by list of files. If indexing is done for that field and
> entries are all associated with their respective files (which I am
> quite positive they are from my last look). A temporary table
> shouldn't be necessary. Temporary tables have other issues such as
> keeping them up to date.
>
> The only issue I see here is that the list of files could be quite
> large when taken into account recursive nature of includes. And, as a
> result, can have some significant impact on queries. This is total
> speculation, though. It could very well be insignificant too. We could
> also limit the files to only one level of include. Which will limit
> the files, and also encourage users to include files for the APIs he
> uses instead of depending on multi-level includes (which is generally
> considered bad practice).

The amount of files given by gcc -MM is usually about 50-200 files so I
think that could significantly slow down queries but I have no numbers
here so it's a wild guess. But that is the reason I was proposing the
temporary db - doing it with queries is fine for me too, maybe there is
even some database feature to allow filtering for multiple searches.

Just to be clear, gtk+ discourages including single header files and
gtk+-3.0 will only allow <gtk/gtk.h> as valid include and error out
otherwise. So, I disagree that this is generally considered bad practice.

I don't know how limiting to one level could work and I don't think that's
useful.

> > As a sidenote, that temporary database could be used for the "File" tab
> > or symbol-db, too.
>
> I find the file tab more useful for searching symbols in the file
> being edited. Searching inside the included files is less useful in
> that context.

Sorry, what I meant was displaying the file tab out of the temporary
database, still only showing the symbols of the current file. This would
mean that there is one backend database and one temporary that would be
used for all queries. But it's probably not worth it anyway.

Thanks for your comments!

Johannes