Siddhartha Singh Sandhu | 5 Feb 23:09 2016
Picon

CEDET compile error

Hi,

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.

Regards.
------------------------------------------------------------------------------
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!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Cedet-devel mailing list
Cedet-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
Frey Florez | 5 Jan 12:54 2016
Picon

Problem to parce C++ string in VC2015

Hello, 

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,

Regards,

Frey 
Attachment (.emacs): application/octet-stream, 9 KiB
------------------------------------------------------------------------------
_______________________________________________
Cedet-devel mailing list
Cedet-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
Dumsani Ndzinisa | 3 Jan 19:54 2016
Picon

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

Hi,

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 
occur.

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.
--
Dumsani
Attachment (.emacs): application/octet-stream, 3618 bytes
Attachment (setup-cedet.el): text/x-emacs-lisp, 725 bytes
------------------------------------------------------------------------------
_______________________________________________
Cedet-devel mailing list
Cedet-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
Evgeniy Dushistov | 13 Nov 02:37 2015
Picon

lazy load?

Hi,

I have something like this in `.emacs`:
(ede-add-project-to-global-list
 (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?

--

-- 
/Evgeniy

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

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

Hi,

 

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

https://www.gnu.org/software/emacs/manual/html_node/ede/Quick-Start.html.

 

To that example, I added a telem_t:

 

include/myproj.hh:

typedef struct

{

  double x;

} telem_t;

 

src/main.cpp:

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,

 

Linh

------------------------------------------------------------------------------
_______________________________________________
Cedet-devel mailing list
Cedet-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
Evgeniy Dushistov | 28 Oct 06:55 2015
Picon

ninja + compdb

Hi,
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
CXX_COMPILER__exe1
CXX_COMPILER__exe2
C_COMPILER_exe3
CXX_COMPILER__lib1
etc

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 build.ninja was changed?

--

-- 
/Evgeniy

------------------------------------------------------------------------------
David Engster | 20 Oct 21:21 2015
Picon

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
    proper.

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.

-David

------------------------------------------------------------------------------
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:

package org.writequit.java;
import java.io.File;

public class Foo extends Thing {

    private String name;

    public Foo(String name) {
        this.name = name;
    }

    public void name(String newName) {
        this.name = newName;
    }

    public String name() {
        return name;
    }
}

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

package org.writequit.java;

import java.io.File;

public class Foo extends Thing<Bar> {

    private String name;

    public Foo(String name) {
        this.name = name;
    }

    public void name(String newName) {
        this.name = 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
Picon
Picon

Semantic database daemon

Hi,

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?

Cheers,
  Lluis

--

-- 
"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
Tollbooth

------------------------------------------------------------------------------
Alastair Rankine | 21 Sep 03:38 2015
Picon
Gravatar

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: https://github.com/martine/ninja/issues/1024

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> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-devel
Stephen Leake | 26 Aug 11:27 2015

commit changes to Emacs core?

I don't see any recent commits on git://git.code.sf.net/p/cedet/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

------------------------------------------------------------------------------

Gmane