On 01/13/2012 09:47 AM, Camden Narzt wrote:
> Hi all,
> I was wondering if I could get some help fixing my CEDET configuration.
> I have two problems (that I know of) the first being that QT (4.7) and CEDET
> don't seem to play nice, I added the QT includes to the list of system
> includes as per: http://alexott.blogspot.com/2009/02/cedet-qt.html but even
> on that page it says it won't work with newer versions of cedet. I get
> errors such as (wrong-type-argument stringp (((0) "qint8"))) all the time,
> especially when trying to use the jump to definition functionality.
The error you quote above looks to me like something got confused in the
C++ preprocessor support. ie - some macro somehow confused things.
Once something bogus gets in, it can be hard to get it out again. You
need to quit emacs, delete your ~/.semanticdb/ cache files associated
with the problem and, perhaps, try again.
Before that, however, use M-x toggle-debug-on-error, and get a stack
trace. That might let you know which file used/introduced the bogus bit
of data. That in turn might lead you to the offending code that got
I don't use Qt, so I won't be too much help here, but the stack might
lead us to the right answer.
> The second issue is that my project is broken down into many smaller
> libraries (compiled by bjam/boost-build), and CEDET seems to be designed to
> have project source code included as "local" includes, not system includes
> which bjam uses. When I try and add all of my libs to the system includes
> everything runs very very slowly, and many includes cannot be found. Looking
> at what documentation I could find it looks like I should be making many
> smaller projects and then having them under a parent project, but I'm having
> severe difficulty understanding the existing documentation on how to do
> that. (I've been reading: http://cedet.sourceforge.net/projects.shtml and
> various pages around
> t.html#ede_002dcpp_002droot_002dproject )
> I'll include my .emacs file at the bottom, for reference.
Your .emacs is quite impressive for trying to get things bootstrapped as
you describe. Remember that the longer things like an include path is,
the slower anything being looked up there will be. I don't know quite
how long that list is. You could try profiling to see where the time is
spent before guessing too much.
Also, if you are aggressive in parsing ALL the code in your project, you
may just be running into a problem where Emacs is too big. Check your
process list when things get slow to see if Emacs is swapping. If so,
cut back to just the code you actually use, and skip the rest.
Lastly, overcoming errors (as you mention above) slows things down, as
there are many cases where errors are skipped, but they may still be
impacting things performance wise.
> (ede-project-autoload "cpp-root"
> :name (getenv "DEPOT_NAME")
> :file 'ede-cpp-root
> :proj-root 'MY-ROOT-FCN
> :proj-file 'MY-FILE-FOR-DIR
> :load-type 'MY-LOAD
> :class-sym 'ede-cpp-root) ; I also
saw this called ede-cpp-root-project
you are right in your comment, I think that is a typo in the comments
I'm not sure how you might be successful with the type in there.