Well, what i am trying to do really is not
only to lookup headers but to be able to let my
ecb-tagdefinition.el - addition to find a tag in my complete
project. Currently it fínds the tag only if the file is loaded.
Klaus suggested running a shell script for parsing all source
files, but this has two problems for me:
- It runs very long (for one directory out of 20 i
let it run for one hour and it did not complete)
- i dont have the impression that the semantic.cache from subdir
 A is found when a lookup from a subdir B of my project for
 a tag definition is done.

Von: Eric M. Ludlam [mailto:eric@siege-engine.com]
Gesendet: Fr 28.01.2005 13:04
An: Jans, Hauke
Cc: cedet-semantic@lists.sourceforge.net
Betreff: Re[1]: AW: [cedet-semantic] EDE Problems


  Since you are only trying to link to include files, I do not
recommend using EDE.  It is heavyweight for that task.

  The -c- path is for finding headers.  The semanticdb-project-roots
variable is for finding database tables.  (and a recent bug posted
indicates this is broken for system files.)  The ECB base directory
thing is for ECB only, and some clever linkage is needed to adopt it's
values into semantic.

  I will see if the -c- variable can be added to both the semantic and
c groups.


>>> "Jans, Hauke" <hauke.jans@sesa.de> seems to think that:
>The project.ede file exists in the toplevel dir and is created in the =
>dir. After that, the error occurs. I am then only able to open
>a file in that directory if i delete the sublevel project.ede file.
>Maybe it has to do with win32-paths?
>For my problem with include paths:
>I did set my project root at the toplevel within ecb.
>But that did not work for me in a way that
>a #include <b.h> in subdir a=20
>finds the file b.h in subdir b.
>Do i need to add all my subdirs to the ecb-project roots
>for this to work?
>I tried the semantic-default-c-path now and it looks good
>after i added all my include paths to that var.
>I did not find that variable, because it is in group "C"
>and not in "semantic" or "ecb" (where i have looked for that).
>Von: Eric M. Ludlam [mailto:eric@siege-engine.com]
>Gesendet: Fr 28.01.2005 05:21
>An: Jans, Hauke
>Cc: cedet-semantic@lists.sourceforge.net
>Betreff: Re[1]: [cedet-semantic] EDE Problems
>  There are lots of ways to configure where include files are found.
>In the case of a C file, there is `semantic-default-c-path'.
>  As for project roots, there is the ECB method (via context menu in
>the directory tree browser).  There is the semanticdb method, via the
>variable `semanticdb-project-roots'.  In EDE, there is the project
>mechanism you defined.
>  As for this specific EDE problem, I'm not sure.  I'd guess it will
>find the new project after the system is saved and emacs is
>restarted.  I seem to recall some frailness in that system for
>sub-projects, but thought I'd solved those issues.  (All of cedet is
>built with EDE and sub projects.)  Did the Project.ede file exist?  I
>think the error means that the project object exists but there was no
>file.  The problem might be a missing save operation.
>>>> "Jans, Hauke" <hauke.jans@sesa.de> seems to think that:
>>After trying to find out what happens when one clicks on
>>the list of includes and wondering why only files from the
>>current directorie are found (and none from my files which
>>reside in other directories) i found that i might need
>>to setup ede-projects.
>>But after creating a toplevel project in my toplevel dir,
>>i tried to create a project in the next lower dir.
>>This gives me the error message / backtrace:
>>Signaling: (error "No project for =3D
>>\Project.ede, but passes project-p test")
>>  signal(error ("No project for =3D
>>\Project.ede, but passes project-p test"))
>>  cerror("No project for %s, but passes project-p test" =3D
>>  apply(cerror "No project for %s, but passes project-p test" =3D
>>  error("No project for %s, but passes project-p test" =3D
>>  =3D
>>  ede-current-project()
>>  #<compiled-function nil "...(14)" [ede-object project-new-target =3D
>>ede-current-project nil ede-buffer-object ede-apply-object-keymap] 2 =
>>("h:\\.xemacs\\cedet-1.0beta3b\\ede\\ede.elc" . 22059) nil>()
>>  call-interactively(ede-new-target)
>>  command-execute(ede-new-target t)
>>  execute-extended-command(nil)
>>  call-interactively(execute-extended-command)
>>This is for XEmacs 21.4.13 and WinXP with cedet-1.0b3.
>>Or is there any other way to tell ECB the paths to all my source
>  [ ... ]
>          Eric Ludlam:                 zappo@gnu.org, =
>   Home: http://www.ludlam.net            Siege: www.siege-engine.com
>Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org