Re: [CEDET-devel] Multiple ede-cpp-root projects

[Krzysztof N. <kr...@op...>]

Hi,

I did some debugging. It looks like the inode matching code gets confused on Win32, because the inode number is always 0, so it always hits the first match.

I disabled this (made ede-inode-get-toplevel-open-project always return nil), but unfortunately now EDE doesn't find any project for my files.

Looks like more digging ahead...

I wonder if reverting the inode matching code introduced in ede-files.c, ver. 1.6 will make it work again.

Regards
Krzysztof
 
"Eric M. Ludlam" <er...@si...> napisał(a): 
 > I tried replicating this on my system with some simple projects on my
 > linux box, but both my test projects seemed to stay distinct.
 > 
 > The only thing I can think of is that drive-letter style paths needed
 > some special code in EDE, but I thought that was working ok.
 > 
 > In one of your files which seems to be getting the wrong header file,
 > you can click with mouse-3 on a header, and choose "Summarize includes
 > current buffer".  It will list the includes paths and EDE projects
 > that were used.
 > 
 > A key function to debug is `semantic-dependency-find-file-on-path'
 > which does most of the lifting for locally found includes.  It may
 > have some issue with choosing the correct EDE project.  For example,
 > if you have several levels of nested includes, it may be that the
 > current buffer at some point may be the wrong EDE project, or no EDE
 > project.
 > 
 > Let me know if you discover any new discrepancies.  Hopefully we
 > can figure out what's going on.
 > 
 > Eric
 > 
 > 
 > >>> Krzysztof Nowicki <kr...@op...> seems to think that:
 > >Hi all,In my setup I'm using multiple ede-cpp-root projects to have
 > >different set of include files and preprocessor defines for each
 > >project. Since we have different copies of the same project trees on
 > >different network drivers, the cpp-root-projects are basically
 > >duplicated, each of them using a different drive letter. The .emacs
 > >file contains something similar to this:
 > >
 > >(ede-cpp-root-project "Some project (F:)"
 > >                      :file "f:/project1/Readme.txt"
 > >                      :include-path '( "f:/project1/include/" "f:/project1/include/test/" )
 > >                      :system-include-path '( "f:/project1/include/" "f:/project1/include/test/" )
 > >                      :spp-table '(("DEBUG" . "") ("DEBUG_EXTRA_TRACE" . "")))
 > >
 > >(ede-cpp-root-project "Some project (G:)"
 > >                      :file "g:/project1/Readme.txt"
 > >                      :include-path '( "g:/project1/include/" "g:/project1/include/test/" )
 > >                      :system-include-path '( "g:/project1/include/" "g:/project1/include/test/" )
 > >                      :spp-table '(("DEBUG" . "") ("DEBUG_EXTRA_TRACE" . "")))
 > >
 > >
 > >After updating cedet to recent CVS I discovered, that when I open a
 > >source file inside f:/project1/, the include directories actually used
 > >by semantic will be from the g:/project1/ directories. In other words,
 > >regardless of where the the source file resides, the last
 > >ede-cpp-root-project in the .emacs file is always used. In older
 > >versions Semantic (previous version I had before the last update was
 > >CVS from Oct. 2008) would choose the project based on the directory of
 > >the project file from the :file field.
 > >
 > >I tried to debug the issue a bit, but I'm no elisp guru. All I found
 > >out was that EDE was correctly asked to retrieve the project for the
 > >.c file and the returned project was correct (i.e. matched the file's
 > >path). I wasn't able explain why is Semantic picking up the wrong
 > >paths.
 > >
 > >I'm using EmacsW32 (GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of
 > >2009-01-01 on LENNART-69DE564 (patched)) on Windows XP, latest CVS
 > >Cedet and ECB 2.32
 >   [ ... ]
 > 
 > -- 
 >           Eric Ludlam:                       er...@si...
 >    Siege: www.siege-engine.com          Emacs: http://cedet.sourceforge.net