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

[Nancí de Brito Bonfim <nancibonfim gmail com>]

On Sun, Dec 12, 2010 at 6:21 PM, Massimo Cora' <maxcvs email it> wrote:

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].

 
Hi all,

why not to have a list of all headers and a relation with each for each package?

The database wouldn't get to big or slow. For instance, we would have:
actual_headers [gtk_header1, gtk_header2, gtk_header3, ..., atk_header1, atk_header2, atk_header3, ..., gdk_header1, gdk_header2, gdk_header3, ...]

and each package would be related to the headers it uses (only the IDs):
package gtk+ [gtk_header1, gtk_header2, gtk_header3, ..., atk_header1, atk_header2, atk_header3, ..., gdk_header1, gdk_header2, gdk_header3, ...]
package atk [atk_header1, atk_header2, atk_header3, ...]
package gdk [gdk_header1, gdk_header2, gdk_header3, ...]

One simple join would limit the actual_headers to the ones in gtk+ or the ones in gdk. When adding a header to a project, we could look for it in actual_headers and just add it to the relation if it's found. Otherwise we add it to actual_headers and make a relation to the current project.
 
If more than a project depends on the same headers, it wouldn't be duplicated (you can easily exclude it in the query).

With a join, you can work in a subset of the headers, just like a "temporary table" and is quite fast. The IDs use few space and they won't make your database go slow with some thousands of entries.

There is a downside with this approach. If some header is updated, the changes won't reflect on the projects depending on it.
We could run a trigger on the database, making it look for every project using that header to also reflect the changes. But the query is fast and the update to each project is atomic.

This way, if a project includes gtk+, it would instantly got (remember, only IDs):
project [project_header1, project_header2, ..., gtk_header1, gtk_header2, gtk_header3, ..., atk_header1, atk_header2, atk_header3, ..., gdk_header1, gdk_header2, gdk_header3, ...]

If we try to associate some headers with just a project and make relations for simple files and projects, that may be harder to maintain and even harder to make it consistent.

Using such relations, which would be actually join tables with package (project) ID and header ID, would waste a few space for a lot of speed, IMHO.

Those are my two cents, although I don't know yet how exactly symbol-db works or if I'm saying something obvious for most of you.

Regards,

-- 
Nanci de Brito Bonfim