>>> Bruce Stephens <bruce+cedet@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>[...]
>
>> Aha, therein lay my own confusion. I remember it working with
>> include files in the same directory as the file I was working on.
>>
>> I also set up a project root, so I get header files from different
>> parts of my tree, but nothing from areas like /usr/include.
>
>I've set up a project root, too, but I don't see how that makes any
>difference.
>
>Project roots will surely make sense in the longer term, because I'll
>want the include path to be per-project. In theory, per directory or
>even per file, but for practical purposes, per-project will work fine.
>
>There seem to be two (connected) aspects to this: one is whether the
>relevant semantic.cache file has been loaded (and it makes sense for a
>project to help with that); the second is relating a tag "foo.h" in
>some file with the file "foo.h" somewhere else in the filesystem.
>
>I'm not sure that a project root helps with the latter. It seems to
>me that the latter has to be done either by some kind of ad-hoc
>searching---look for any foo.h, or perhaps look for the closest foo.h
>or something---or, more practically, look in the include path.
I think you are right. There are two ways to search through
databases. There is the "go through the include files" which is
supposed to use the include path, and there is the "brutish"
mechanism wich scans all files within the project. I think I've
confused myself somewhere in my previous description.
>[...]
>
>>>So I think my best bet is to try uncommenting that code, and see how
>>>it works out for me.
>>
>> Good Luck. I found that it "worked", which made me happy. Then I
>> tried to use it in a real situation, and the setup for the different
>> queries took a long time which I found irritating. Basically, I
>> need a way to automate first-time setup in a smart way so as to
>> minimize the pain.
>
>I see what you mean. It's much too slow for me to use.
>
>There are several things involved. One is parsing the various files
>(191 according to gcc -M, for the file I tried with). That's going to
>take time, but I can live with it---it's something that can be done
>overnight. (It would be unacceptable for someone just starting to use
>cedet, so some of the automated aspects need to be disabled by
>default, as you say.)
There is a shell script "semanticdb.sh" which will let you process
the files from a Makefile, cron, or whatever.
>Another is the backend storage---one file per directory is probably
>going to be OK, except that some of these files are rather big. So
>when I'm trying to get information about some non-SSL related function
>in a file which #includes openssl/ssl.h or something, I need to wait
>while the 1.8M semantic.cache file relating to include/openssl gets
>read. Yuck. Even worse, the commented out section seems to load the
>databases by visiting the files, so not only do the tables get read, I
>also get Emacs buffers (font-locked, imenu, etc.), for files that I'm
>mostly not interested in.
There is a "system" database back end. You can create a system
database via the command:
M-x semanticdb-create-system-database RET
The way it is "supposed" to work is that if you want tags from some
system header file, you can find it from one of these system
databases. Unfortunately, I think the logic is a bit screwy right
now where "brutish" searches scan systems, but header file jumping
does not.
Ideally, the code you are looking at should "fetch the tokens from"
the header file (instead of jumping to the file as you identified).
For system includes (marked as such in the semantic tag) it could
look for in this database.
System databases are loaded at Emacs start time when cedet is loaded
and semanticdb is activated, so a large systemdb would burn cycles
then.
This interaction is something I just haven't gotten to yet.
>I guess I need a proper database backend, so that the code can ask for
>the specific information it wants without having to read in irrelevant
>stuff that happens to be in the same directory. That won't help
>creation of the information, but I think I can live with that (as
>mentioned above, mostly that can happen in batch mode).
>
>Has anyone written an alternative backend for semanticdb?
[ ... ]
There are different types of back ends. The semanticdb-el.el library,
for example, is a back end that directly queries Emacs' table of
loaded symbols. I believe there is a similar library being made for
java .class or .jar files.
I thought it would be cool to have an alternative to semanticdb-file
which would save tag info in postgres or mysql. This sort of
database would be ideal for system databases that you are hoping to
use. For projects, file's may be more useful, but for the whole
system, a read DB might be best.
There is an accommodation for this occurring inside the core
semanticdb classes, but of course it has not been tested. There are
just oh-so-many things to do.
If you contemplate doing this, you will be pleased to not that the
core methods to override are quite simple. If you examine
semanticdb-file.el, you will see that you just need your new eieio
classes, and to override the methods:
semanticdb-create-database
semanticdb-save-db - which may not be needed for a real db
semanticdb-full-filename - perhaps, not sure
In your case, you would also need to implement a new class for
semanticdb-table, where the table implements semanticdb-get-tags,
which may or may not choose to cache tags out of the database. I
only recently started putting more restrictions on access to a
table's tags. For a DB backend to be useful, blindly fetching all
the tags should be pushed down to 0 for application use. That could
take some time and thought, but could be worked around short-term for
an alternate back end.
That may be all for basic manipulation. After that, of course, you
need to implement all the query functions which is where the real
benefit to an SQL backend would lie.
Upon examination of the semanticdb table, I see I wasn't very clean
about where some slots are. That semanticdb table implementation
could prove challenging. Hmmm.
Good Luck
Eric
--
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
|