Re: [cedet-semantic] Including files from subdirs

[Michael R. <re...@gm...>]

On Friday 23 May 2008 15:58, Eric M. Ludlam wrote:
>
>   The reason semanticdb doesn't do include searches generically from a
> single root is that 1) a project might be huge, and it would take a
> long time, or 2) ccc.h might show up multiple times in different
> modules under the same general project.
Hmm, fair enough.

>
>   I recommend the ede-cpp-root which you setup as a 2 line
> configuration.  If you project is particularly complex, you can write
> a function to provide the include path based on location in a project.
>
>   ede-cpp-root is described briefly in the common/cedet.info manual
> for c++ configurations and that should get you started.
Ok, so I played around with that a bit today. It works as fine so far. Even 
the macros stuff. Cool!

I have a few annotations though, if you don't mind :)

- It would be nice to be able to put the project spec into a separate file in 
the project root, to not clutter the .emacs file with all kinds of 
projects ... and maybe a command to create a skeleton for me, where I just 
fill in includes and macros (interactively?)
- sometimes I was curious which include directories are actually taken into 
account for a certain file or if a project was actually loaded. Getting some 
info about this would be nice. In case its intended therefor, I tried 
ede-adebug-project. However I just get:

Symbol's function definition is void: semantic-adebug-new-buffer

- It would be cool to be able to reload a project spec on the fly after doing 
a modification to includes or macros, right now it seems I have restart 
XEmacs after every change ... So something like M-x ede-reload-project 
<Return> (this would require the separate file thing above I guess?)

- something I stumbled across: ede-customize-project in eieio-custom.el uses 
overlay-lists, which gets me "Symbol's function definition is void: 
overlay-lists" with XEmacs. In semantic you do: 

(defalias 'semantic-overlay-lists
        (lambda () (list (extent-list))))

so something similar is probably needed here as well...
>
>   The semanticdb-project-roots is for a "brutish" search.  (The second
> type of search.)  For a brutish search, every database under the
> project root will be scanned, but new currently unparsed files will
> not be.  (Again, a speed issue.)
>
Hmm, maybe the docu for semanticdb-project-roots should be clearyfied? As 
noted, it says: "All subdirectories of a root project are considered a part 
of one project.". However it's still not clear to me what being "part of one 
project" actually means? When I need to specify the subdirectory on the 
#include i.e. "sub/ccc.h", then for me it takes into account only the project 
root directory as "include path", but ignores the subdirectories ... as 
otherwise "ccc.h" would be enough ...? (The database file for ccc.h is 
present in ~/.semanticdb so the "but new currently unparsed file" part should 
not be relevant, right?)

Greets Michael