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

[Massimo Cora' <maxcvs email it>]

Hi,

On 12/12/2010 02:16 PM, Johannes Schmid wrote:
> Hi!
>
> > On 12/10/2010 04:14 PM, Sébastien Granjoux wrote:
> > > Then, is the symbol db plugin interested by knowing the packages ?
> > >
> > > I think it could be easier to send it directly all the header files
> > > without splitting them in packages. One thing that is interesting though
> > > is to tell to the project manager which header files are associated with
> > > which source files. By example having
> >
> > the packages' names are required to reduce the files scanned when an
> > user opens a project with a subset of the whole global packages saved.
> > If you put everything a default package then you would soon have
> > scalability problems.
>
> I don't see your point here. The symbol-db just has to check if the needed
> file is in the symbol-db already or not. If not, it is scanned, if it was
> already there, nothing is done.

In Anjuta 2.32 there was a problem with global packages and 
dependencies: the gtk+ package for instance had more than a dependence 
package, so that even gdk/atk/etc headers files fell under 'gtk+' 
package, voiding the atk/gdk ones.
Schematizing
package gtk+ [header1, gtk_header2, gtk_header3, ..., atk_header1, .... 
gdk_header1...]

That could be fixed using the --print-requires and similar flags to 
pkg-config.
This hasn't been implemented yet, but if we did we would have something 
like:
package gtk+ [gtk_header1, gtk_header2, gtk_header3, ...]
package atk [atk_header1, atk_header2, atk_header3, ...]
package gdk [gdk_header1, gdk_header2, gdk_header3, ...]

By using this schema we can have easier queries filtering the packages 
[and then their headers] directly in the sql.

Putting everything in a default package like:

package default [gtk_header1, gtk_header2, gtk_header3, ..., 
atk_header1, atk_header2, atk_header3, ..., gdk_header1, gdk_header2, 
gdk_header3, ...]

no more quick filtering is performed and a manual passing of headers as 
parameters would be required, slowing the process.
More: an user can have a project with no gtk/glib libraries at all, but 
using default package would check for all headers in the global db.

Then yes, we can have both the packages filtering [that are loaded at 
project loading time] and the special single-file-header filtering 
[detected by the #include parameter].


regards,
Massimo