Re: [anjuta-devel] New project-manager and symbol-db



Hi Johannes,,

Le 18/11/2010 15:55, Johannes Schmid a écrit :
There seems to be a bug in the way the project-manager and symbol-db
work together. Basically the whole project is rescanned on each
start-up. Don't know exactly why this happens.

Currently, the symbol-db doesn't use the package found by the project manager. It get only the module names and is finding the package itself using the old ianjuta_project_manager_get_packages function.

Then, the project is not loaded in one time. It's quite possible that symbol-db plugin see a project without any packages and see new package afterward. It's possible to fix it but I don't know what is the best solution to do it.


It also seems that something is causing anjuta to be very slow in the
10s after a big project was opened. I expect the symbol-db to do some
(probably unnecessary) work but not sure.

It's quite possible due to the symbol-db plugin rescanning everything. The project manager needs some time to get all sources files of all packages.

With the --print-requires switch we are able to sort these paths out to
only get those files to belonging to the particular packages. But I am
not sure how we should interact with the project-manager there and how
the project-manager would work together with symbol-db.

Me neither at the moment.

I don't know if a tree like this would be acceptable for the
project-manager:

->  MODULE
  ->  GTK
    ->gtk+-2.0
      ->gtk-only files
      ->glib-2.0
        ->glib files
      ->atk-2.0
        ->...
out of this source: PKG_CONFIG_MODULE (GTK, gtk+-2.0).

It's not working like this currently, but it's acceptable.

The other issue still open is with packages that return something like
"/usr/include" as the include path, while their real files are inside
"/usr/include/<package_name>.

The idea is to have some (hard-coded) mapping for such packages. That
isn't really nice but would solve the problem and is easy to implement.
It is a bit of a pain to maintain of course.

I think it would be better to extract the include files from the source itself. So rather in the language-support plugin.

Then, I think it would be better that instead of having the symbol-db plugin requesting the header files. Each plugin which knows the header files send them to the symbol-db plugin. In C, the language support plugin and the project manager. For python, I think they are defined with import, so known by the language support plugin only.

I don't know how to send this information though. Perhaps having a function in the symbol-db which is called by other plugin. Or having a signal emitted when a new header is known. This last solution will allow several plugins to know these headers not only the symbol-db plugin.


Best Regards,

Sébastien



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]