Re: Multi-directory stuff

"Eric M. Ludlam" <eric <at> siege-engine.com> 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.

[...]

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

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.

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?

[...]

-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8