[anjuta-devel] RFC: Symbol-db future



Hi!

As a follow-up of yesterday's IRC discussion some ideas how a future
symbol-db could work.

Global-DB:
----------

General:
The symbol-db should automatically scan all symbols from packages we can
find using the pkg-config parsing of the project manager (+ meta-package
for libc and libstdc++). As this depends on the language used (and it
doesn't make sense to create a database if we have only non-C languages
used) this will be handled by the language-support plugin:

* Get the packages from the project-manager
* Check for dependant packages and their include dirs (new libanjuta
API)
* Call ianjuta_symbol_manager_add_package() for all needed packages
(we can skip package_(de)activate probably - see below)

Get exact symbols for a file :
(see https://bugzilla.gnome.org/show_bug.cgi?id=630198)

We can get a list of files included by a particular source file using
"gcc -MM file.c -I..." and as we know the include directories from
pkg-config we can also easily add the needed -I flags. This is also a
responsibility of the language-support plugin.

As it would take too long to rescan those files everytime and we already
have the global database I was thinking about creating a temporary
(in-memory) database holding only the symbols we want. Pseudo SQL

SELECT WHERE (file-list contains filename) from symbols >> temporary
database

While we still might want to do this query in an async fashion this
should be reasonable fast (<< 1 sec) for creating the temporary
database. Searches would be performed on the temporary database. We
could even do the same for the project files database but two problems
arise:

* gcc only gives us relativ paths for those files (well, we can solve
this)
* we would need to update the temporary database when the file is saved
by keeping the project database consistent. That could be tricky. On the
other hand we probably want to regenerate the database anyway when the
file is saved because there could be more include files now.

As a sidenote, that temporary database could be used for the "File" tab
or symbol-db, too.

Advanced queries (lower priority)
----------------

I think I posted about this some months ago. Actually we would need
something like this (simplied)

symbol_query_in_scope (SymbolIter* scope, const gchar* search_string)

which would return all found symbols that are available in scope
including those of global scope. As an example if the scope is a method
inside a class:
->scope of method
 ->scope of file
 ->scope of class
  ->scope of parent class(es)
   ->scope of namespace
->global scope

This would make C++ autocompletion really easy and probably also make
the code in language-support-cpp-java much shorter especially when all
queries only go to the temporary database. Maybe that's easy SQL, maybe
it means reorganizing that database, I don't know. It's not
high-priority but would be nice to have.

So, does this make sense to you. Am I overseeing something important? Is
this difficult to implement? I will do the stuff in language-support
(and libanjuta) if necessary but I have still no real idea how symbol-db
fits together...

Thanks for reading,

Johannes
 

Attachment: signature.asc
Description: This is a digitally signed message part



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