>>> <klaus.berndl@...> seems to think that:
[ ... ]
>I agree with you concerning the understandability of the=20
>Well, the need and usage (and also when is needed) of the settings
>in `semanticdb-project-roots' and `semanticdb-project-root-functions'
>are one of the biggest mysteries in using cedet ;-)
>But i admit - i have not really digged deep into this stuff but i can
>at least say, its not intuitively...
[ ... ]
Semanticdb complexity is certainly an issue. It is a rather hairy
problem to try and solve.
The basic organization is this:
defines a "database" and a "table" baseclass. You can
instantiate these classes, and use them, but they are not
This file also provides support for semanticdb-minor-mode, which
automatically associates files with tables in databases so that
tags are 'saved' while a buffer is not in memory.
Lastly, it has that "root" stuff in it. Basically, it is a
system by which a file can be associated with the root of a
project, so if you have a tree of directories and source files,
it can find the root, and allow a tag-search to span all
available databases in that directory hierarchy.
Subclass the baseclass database so that it can be saved to disk.
Implements all the hooks needed to unbind/rebind tags to a buffer
while writing them to a file. Overrides various methods as
Subclass semanticdb-file. Supports creating a DB in a directory
you do not have write-access to, and saving the cache in your
home directory. Also implements a C/C++ subclass which can be
used for caching /usr/include. (A rather slow process.)
Implements a different kind of "system" database that uses emacs
internals to perform queries. Sadly, this shows a problem of
nomenclature since it is not a semanticdb-system-database (which
saves to a file), but database with no file component that
queries system tags in a different way.
Infrastructure for searching groups semantic databases, and
dealing with the search results format.
Here are some new things I'd like to write, or see written someday.
Any DB would do, mysql would be fine. Basically write tags into
a relational database, and provide searching facilities. This is
probably the only way to allow fast lookups in humongous source
areas. Another possibility would be something like what cscope
A system database for java that uses JDEE beanshell queries.
A system database that uses command line tools to rip symbols out
of .so, or .a, or .o files, and translates into tags.
This is just an overview really. If you have specific questions, I'd
love to try and answer them since it would then provide excellent
sources of new documentation to add to the semantic doc, or ways to
fix the doc-strings of certain configurable variables.
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org