Re: [cedet-semantic] Including files from subdirs
Brought to you by:
zappo
From: Michael R. <re...@gm...> - 2008-06-07 22:58:09
|
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 |