Siddhartha Singh Sandhu | 5 Feb 23:09 2016

CEDET compile error


I am trying to compile cedet-1.1 form the binaries with:
 $ make

I also tried all the other make commands after `make clean-all` but I receive the same error.

My compilation is failing on the following step:

In eieiodoc-one-node:
eieio-doc.el:118:15:Warning: reference to free variable `indexstring'
eieio-doc.el:130:56:Warning: reference to free variable `root-class'
eieio-doc.el:138:42:Warning: reference to free variable `rclass'
Wrote /home/sid/.emacs.d/cedet-1.1/eieio/eieio-doc.elc

In toplevel form:
eieio-base.el:42:11:Error: Invalid function: object-class-fast
Wrote /home/sid/.emacs.d/cedet-1.1/eieio/eieio-datadebug.elc
make[1]: *** [eieio] Error 1
make[1]: Leaving directory `/home/sid/.emacs.d/cedet-1.1/eieio'
make: *** [eieio] Error 2

Env Details:

1. Ubuntu 14.10
2. Emacs 24.5.2

Please advice on how I can fix this.

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
Cedet-devel mailing list
Cedet-devel <at>
Frey Florez | 5 Jan 12:54 2016

Problem to parce C++ string in VC2015


I am trying to create a C/C++ IDE in emacs. As part of the process I installed CEDET package. The parser is working with 
.h header and structs, classes etc. The problem appears by using the C++ <string> header

std::string s1;
s1.                  //parsing problem 
Attached my .emacs file.

I appreciate your help,


Attachment (.emacs): application/octet-stream, 9 KiB
Cedet-devel mailing list
Cedet-devel <at>
Dumsani Ndzinisa | 3 Jan 19:54 2016

Wrong type argument: stringp, nil on global-ede-mode


Firstly, I'm a new CEDET user in Emacs, not a developer as such. So please forgive me if
I'm posting to the wrong list.

I've recently learnt about CEDET and it's amazing power to transforming Emacs
into an even better programming/development environment. I have been reading and trying
to follow a bunch of online articles about how to add the customizations in my init file and get
things working.  In particular, I've closely followed advice from 

However, the process always fails when the line (global-ede-mode) gets executed in my
init file. I am attaching my init file (~/.emacs) as well as my customization file for setting
up CEDET (as guided by one of the sources I mentioned above). 

I'm using Emacs 25.1.5, installed from source (on GNU Linux Mint, gcc/g++ 4.8, x86) after
cloning the Emacs' git repo. There is a stock CEDET installation coming with this version
of Emacs, and according to my Emacs package manager (M-x cedet-version), the version
of CEDET in  here is 2.0.

It is probably worth mentioning that when I fire Emacs with the -Q option and then simply
type M-x global-ede-mode, the EDE mode gets enabled successfully, The error does not 

Could anyone please help! I really like the functionalities provided by CEDET, particularly
the source code navigation and intelligent completion. 

Thank you in advance for your kind assistance.
Attachment (.emacs): application/octet-stream, 3618 bytes
Attachment (setup-cedet.el): text/x-emacs-lisp, 725 bytes
Cedet-devel mailing list
Cedet-devel <at>
Evgeniy Dushistov | 13 Nov 02:37 2015

lazy load?


I have something like this in `.emacs`:
 (ede-compdb-project "clang"
		     :file "/home/evgeniy/projects/os_bugs/clang/llvm/CMakeLists.txt"
		     :compdb-file "/home/evgeniy/projects/os_bugs/clang/build/compile_commands.json"
		     :compile-args '("-k" "-j5")

Every time I run emacs it reload `compile_commands.json`,
which take big amount of time in llvm/clang case,

Is it expected behaviour of EDE (I used recent from git)?

I thought before that ede load suitable project only
if open something under the root of project, not at
the moment when I start emacs without arguments? 

Can it be tweaked to lazy load of project,
only when I open source files that part of project?



Phan, Linh H (3443 | 2 Nov 21:41 2015

semantic-ia-fast-jump: Could not find suitable jump point



  I am having problem using "semantic-ia-fast-jump" using the example:


To that example, I added a telem_t:



typedef struct


  double x;

} telem_t;



int main() {

  telem_t telem;



When I put my mouse on "telem_t" in main, I see the definition of telem_t in the ECB symboldef buffer (and I see myproj.hh has been loaded into emacs),  but when I run M-x semantic-ia-fast-jump, emacs says:

Could not find suitable jump point for telem_t


If I put the below in my .emacs:


(defun my:add-semantic-system-include()

  (semantic-add-system-include "/home/phan/pkgs/ede/example/include" 'c++-mode)


(add-hook 'c-mode-common-hook 'my:add-semantic-system-include)


Then when I run M-x semantic-ia-fast-jump, emacs would successfully jump to telem_t definition in myproj.hh.

myproj.hh is not a system include file and so I was hoping for a better solution than this.


Thanks for any help,



Cedet-devel mailing list
Cedet-devel <at>
Evgeniy Dushistov | 28 Oct 06:55 2015

ninja + compdb

I try to use ede-ninja-project,
and it looks too dificult for me for every day work.

The problem in build-rules,
for my project (3 library plus 10 executable)
cmake (3.3.2) generate such rules like

so I need hold in my .emacs list of this ":build-rules"
and update them to make them consistent with project.

Why not just parse "ninja -t commands" every time
when was changed?



David Engster | 20 Oct 21:21 2015

RFC: Moving CEDET development to Emacs

Hi Eric and all,

tl;dr: I propose we move CEDET development to the Emacs repository.

The long story:

Emacs switched to Git some time ago, and so did we. This broke my
Bazaar-based setup for merging the CEDET SourceForge-Repository with
Emacs. I tried to re-create that setup with Git, but I gave up. Not
because it is too difficult, but because I realized that I really,
really do not want to keep doing these merges.

While I pretty much automated everything that could be automated (see
cedet-emacs-merge.el), these merges still involve a *lot* of grunt work,
including fixing commit message so that Changelogs adhere to Emacs
standards, fixing merge conflicts, and fixing compatibility problems
with newer Emacsen. All of this stuff is complicated because CEDET files
are scattered across the Emacs repository, and a lot of stuff that is
upstream is not in Emacs core.

Also, EIEIO was partly rewritten in Emacs 25. Fixing CEDET in a way that
works both with Emacs 24.x and 25 and not drowning in hundreds of
byte-compiler warnings will be another big hassle, so I'd rather
completely switch to the new EIEIO.

So here's my proposal:

  - We move CEDET development to Emacs proper, maybe on its own branch
    (might be necessary for times where Eric does not have a copyright
    lease from his employer).

  - We split off the stuff that is not part of Emacs, but for which
    papers were signed, into one or several ELPA package(s). When some
    of them are considered mature enough, we would merge them to Emacs

This also means that:

  - We do not provide a "separate CEDET" anymore.

  - We only target the current Emacs development version.

  - The stuff in 'contrib', for which we don't have papers, has to
    stay somehwere else, like Sourceforge or GitHub.

  - We will loose a lot of commit history (it will be only available in
    the old repo).

I'm not proposing this lightly. Dropping support for older Emacsen is a
pity, since we will loose a lot of testers. I considered several
alternatives, but I really think it is time we make this step.

On the bright side, I think that moving development to Emacs and
dropping 24.x compatibility will give us new freedom to react
quicker. If you follow emacs-devel, you know that there's a lot of
discussion w.r.t. to new APIs for IDE-like features. I really want CEDET
to be a part of that, and I think this will be easier if we work
directly in Emacs.


Lee Hinman | 15 Oct 23:56 2015

Parsing Java classes that extends classes with Generics

Hi Cedet,

I've noticed that Semantic parser doesn't seem to be able to handle
classes that extend other classes with generic parameters, for example,
take this class:


public class Foo extends Thing {

    private String name;

    public Foo(String name) { = name;

    public void name(String newName) { = newName;

    public String name() {
        return name;

Everything parses great from this (class name, variables, functions,
etc), however, if I change the file to be:



public class Foo extends Thing<Bar> {

    private String name;

    public Foo(String name) { = name;

    public void name(String newName) { = newName;

    public String name() {
        return name;

Semantic is suddenly unable to parse anything except for the package and
import (it chokes at the `Thing<Bar>`).

I'm using the latest CEDET from the master branch loading it with:

(load-file "~/src/elisp/cedet/cedet-devel-load.el")

At the very top of my Emacs init.

Is there something I can do to get Semantic to parse this correctly? I
really rely on Semantic parsing useful information for my day-to-day
Java development.


;; Lee Hinman

Lluís | 13 Oct 15:34 2015

Semantic database daemon


I have some vague memory that the possibility for a semantic database daemon was
discussed in this list to provide asynchronous file processing (aka, without
blocking the editor; was it Eric?). I think that another possibility was keeping
the in-memory symbol database small, and (un)loading info from database files on
demand. It was all discussed as a response to Emacs getting blocked on semantic
on large projects (I could not find the thread).

Does anybody remember these discussions? What about the amount of work they
might require? Do both match the database daemon scheme, or was it just the
asynchronous part that required the daemon?



"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom

Alastair Rankine | 21 Sep 03:38 2015

Issue with ede-ninja-project and CMake

I discovered recently that a change in CMake has broken compatibility with ede-ninja-project.

Basically ede-ninja-project uses the native capability of the ninja build tool to generate a compilation database on the fly. In order to do this we need to specify the name of the appropriate build rules which we want to see in the output. By default, the ede-ninja-project type uses the rule names “C_COMPILER” and “CXX_COMPILER”, which were until recently the default rule names for CMake.

In the recent 3.2 release (or possibly earlier) of CMake, a change was made to the names of the build rules it generated within ninja’s build file. Instead of “CXX_COMPILER”, it will now generate build rules with names such as “CXX_COMPILER__proj”. In other words, the build rule names are no longer stable, and hence cannot easily be used with ede-ninja-project.

Workaround: For now I suggest using CMake’s CMAKE_EXPORT_COMPILE_COMMANDS variable to export a compile_commands.json file, which can be used with the regular ede-compdb-project type.

I think this is ultimately a Ninja problem, and I have raised it with them, see here:

I have also added an expected failure for the affected ninja unit test within CEDET. This is intended to allow the unit tests to execute cleanly when a recent version of CMake is installed. Unfortunately there is something about the CEDET utest environment which prevents it from working correctly - instead of recording a test failure it records an aborted test case. I looked into this briefly but couldn’t work out why it was behaving like this - any advice appreciated.

By the way, I still intend to remove the runtime dependency on cmake and ninja for the unit tests of compdb - which should also fix the expected failure.

Cedet-devel mailing list
Cedet-devel <at>
Stephen Leake | 26 Aug 11:27 2015

commit changes to Emacs core?

I don't see any recent commits on git://, in
particular the patch to add mode-local overrides to describe-function.

I'm working on a similar patch for xref-find-definitions.

Should I commit these to Emacs core?


-- Stephe