Thread: [cedet-semantic] Pending CEDET issues
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2008-03-04 12:27:56
|
Hello all, There have been a bunch of significant changes to CEDET in CVS and I'd like to put another general release out. If you know of any pending issues that should be fixed that I may have missed or forgotten about, please let me know. I've been through the bug tracker, and have dealt with the items I know how to deal with. In particular, I only really code in M, C++ and Emacs Lisp on Emacs 22/23. If you use a different language or Emacs version and know of some issues, or could try out some of CEDET's recently updated features from CVS, such as in code-completion, templates, documentation, whatever, then that would be great. Lastly, the CEDET manual (in common/cedet.texi) has new chapters for configuring CEDET that are application specific. It describes what to do if you want to use ECB, JDEE, or just do C++ programming with CEDET, for example. If you use CEDET with some other big tool, or just use it differently than in the manual, I'd love to see your configuration, and include those configuration ideas into the CEDET manual. Thanks! Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Michael R. <re...@gm...> - 2008-03-04 15:11:42
|
On Tuesday 04 March 2008 13:27, Eric M. Ludlam wrote: > Hello all, > > There have been a bunch of significant changes to CEDET in CVS and > I'd like to put another general release out. If you know of any > pending issues that should be fixed that I may have missed or > forgotten about, please let me know. I've been through the bug > tracker, and have dealt with the items I know how to deal with. > I have a few small issues on the list I worked around locally. First when building srecode it fails with: While compiling toplevel forms in file /home/michael/Scripts/site-lisp/cedet-cvs/srecode/srecode-filters.el: !! File error (("Cannot open load file" "newcomment")) There seems to be no newcomment in XEmacs 21.4. In other files you do: semantic/semantic-util.el: ;; Emacs 21 (condition-case nil (require 'newcomment) (error nil)) So I guess that's just missing. Secondly when opening a file I get: Symbol's function definition is void: subst-char-in-string There seems something wrong with autoloading it. I load cedet-compat.el manually. Third I sometimes have code (C++) like: ... delete a; ... a = getA(); ... Then after the delete "a" is treated as type "class delete". Greets Michael |
From: Eric M. L. <er...@si...> - 2008-03-05 04:27:08
|
>>> Michael Reiher <re...@gm...> seems to think that: >On Tuesday 04 March 2008 13:27, Eric M. Ludlam wrote: >> Hello all, >> >> There have been a bunch of significant changes to CEDET in CVS and >> I'd like to put another general release out. If you know of any >> pending issues that should be fixed that I may have missed or >> forgotten about, please let me know. I've been through the bug >> tracker, and have dealt with the items I know how to deal with. >> >I have a few small issues on the list I worked around locally. > >First when building srecode it fails with: > >While compiling toplevel forms in >file /home/michael/Scripts/site-lisp/cedet-cvs/srecode/srecode-filters.el: > !! File error (("Cannot open load file" "newcomment")) > >There seems to be no newcomment in XEmacs 21.4. In other files you do: > >semantic/semantic-util.el: > ;; Emacs 21 > (condition-case nil > (require 'newcomment) > (error nil)) > >So I guess that's just missing. Thanks for pointing that out. I'll put in the same condition case. I think that's in there just to quiet byte-comp warnings. >Secondly when opening a file I get: > >Symbol's function definition is void: subst-char-in-string > >There seems something wrong with autoloading it. I load cedet-compat.el >manually. This I'm not sure about. Does it show up in the cedet-loaddefs.el file? >Third I sometimes have code (C++) like: > >... >delete a; >... >a = getA(); >... > >Then after the delete "a" is treated as type "class delete". [ ... ] Delete was not listed as one of the keywords. I've added this to the parser, but I can't check it in at the moment as I'm re-writing parts of the C++ parser to try and improve the pre-processor to account for some other bugs. When I finish that this ought to be better. Thanks for the info! Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Michael R. <re...@gm...> - 2008-03-05 10:10:02
|
On Wednesday 05 March 2008 05:26, Eric M. Ludlam wrote: > >>> Michael Reiher <re...@gm...> seems to think that: > >Secondly when opening a file I get: > > > >Symbol's function definition is void: subst-char-in-string > > > >There seems something wrong with autoloading it. I load cedet-compat.el > >manually. > > This I'm not sure about. Does it show up in the cedet-loaddefs.el file? > No. When building it says: Generating autoloads for common/cedet-compat.el... so it's processed at least. It ignores autoloads encapsulated by: (when (not (fboundp 'compare-strings)) (if (not (fboundp 'subst-char-in-string)) However it doesn't seem to really matter what the whens/ifs evaluate. It's seems to be their mere presence which keeps the functions from being added to autoloads... Greets Michael |
From: Tom T. <tr...@re...> - 2008-03-08 20:55:12
|
>>>>> "Eric" == Eric M Ludlam <er...@si...> writes: Eric> There have been a bunch of significant changes to CEDET in CVS Eric> and I'd like to put another general release out. If you know of Eric> any pending issues that should be fixed that I may have missed Eric> or forgotten about, please let me know. Would you consider making a package for ELPA? In case you don't know about it, ELPA is a hosting site for Emacs packages, that has a simple client-side elisp manager. See the ELPA site for more info: http://tromey.com/elpa/ For most large packages, like CEDET, ELPA support means adding a single file to the distribution. However, sometimes it is not simple, depending on package layout, compilability, how activation works. Anyway, if you are at all interested in this, I'd be happy to go into the details, and also help out a bit. The reason to package for ELPA, IMNSHO, is that it is the simplest way for end users to install Emacs packages -- it is as easy as using the buffer menu. FWIW I've been meaning to look into packaging CEDET myself, but time is limited, and I generally like support from the package maintainers anyhow. A pending release seems like a good time... thanks, Tom |
From: Eric M. L. <er...@si...> - 2008-03-09 17:49:42
|
>>> "Lennart Borgman (gmail)" <len...@gm...> seems to think that: >Eric M. Ludlam wrote: >> That would be fine by me. I'm not too picky about that sort of >> thing. My primary goal is to get EDE (a part of CEDET) to generate >> Makefiles that work as well as possible when installing CEDET. ELPA > >Would it be possible to use elisp code instead of makefiles? That would >make it much easier for us living in the w32 world. EDE already supports this, though I never scripted all the independent parts together. I've just started putting a cedet script together for building all the Emacs Lisp and it doesn't look too bad. We'll see how it goes. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Eric M. L. <er...@si...> - 2008-03-11 02:41:59
|
>>> "Lennart Borgman (gmail)" <len...@gm...> seems to think that: >Eric M. Ludlam wrote: >>>>> "Lennart Borgman (gmail)" <len...@gm...> seems to think that: >>> Eric M. Ludlam wrote: >>>> That would be fine by me. I'm not too picky about that sort of >>>> thing. My primary goal is to get EDE (a part of CEDET) to generate >>>> Makefiles that work as well as possible when installing CEDET. ELPA >>> Would it be possible to use elisp code instead of makefiles? That would >>> make it much easier for us living in the w32 world. >> >> EDE already supports this, though I never scripted all the independent >> parts together. I've just started putting a cedet script together for >> building all the Emacs Lisp and it doesn't look too bad. We'll see >> how it goes. > >That sounds very promising. I guess you have some generic approach to >the elisp build scripts? EDE is a project management system. I use it to manage the CEDET build process and create all the Makefiles. It also knows how to compile it's own targets from within a running Emacs. There is now a cedet-build.el in CVS that can build all the Emacs parts of CEDET. I tested this on Emacs 23.0 and it seems to work. It found a few bugs in other parts of CEDET too, so you will need to update your CVS copy of CEDET to try it out. DO NOT use cedet-build.el in a running Emacs with CEDET enabled. Compiling EIEIO while CEDET is running will corrupt some of the data structures. Enjoy Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Eric M. L. <er...@si...> - 2008-03-09 02:40:58
|
>>> Tom Tromey <tr...@re...> seems to think that: >>>>>> "Eric" == Eric M Ludlam <er...@si...> writes: > >Eric> There have been a bunch of significant changes to CEDET in CVS >Eric> and I'd like to put another general release out. If you know of >Eric> any pending issues that should be fixed that I may have missed >Eric> or forgotten about, please let me know. > >Would you consider making a package for ELPA? In case you don't know >about it, ELPA is a hosting site for Emacs packages, that has a simple >client-side elisp manager. See the ELPA site for more info: > > http://tromey.com/elpa/ > > >For most large packages, like CEDET, ELPA support means adding a >single file to the distribution. However, sometimes it is not simple, >depending on package layout, compilability, how activation works. > >Anyway, if you are at all interested in this, I'd be happy to go into >the details, and also help out a bit. The reason to package for ELPA, >IMNSHO, is that it is the simplest way for end users to install Emacs >packages -- it is as easy as using the buffer menu. > >FWIW I've been meaning to look into packaging CEDET myself, but time >is limited, and I generally like support from the package maintainers >anyhow. A pending release seems like a good time... [ ... ] Hi, That would be fine by me. I'm not too picky about that sort of thing. My primary goal is to get EDE (a part of CEDET) to generate Makefiles that work as well as possible when installing CEDET. ELPA may find it useful to use the `inversion.el' file that is in CEDET for version dependencies. I've found it helpful. It looks like ELPA tries to do fancy stuff with autoload cookies. The CEDET build choreographs the generation and use of these things a great deal. It seems unlikely that ELPA would want to get in the middle of all that, though ELPA may want to use some of CEDET's autoload additions that support EIEIO classes and batch mode in all Emacsen. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |
From: Eric M. L. <er...@si...> - 2008-03-11 11:59:50
|
>>> Tom Tromey <tr...@re...> seems to think that: >>>>>> "Eric" == Eric M Ludlam <er...@si...> writes: > >Eric> ELPA may find it useful to use the `inversion.el' file that is >Eric> in CEDET for version dependencies. I've found it helpful. > >I looked at inversion.el a while back, and while it does look good, >I'm trying to keep package.el dependencies minimal. ATM I'm not even >using the version comparison stuff in Emacs 22, instead rolling my own >(lame) variant :( > >Eric> It looks like ELPA tries to do fancy stuff with autoload cookies. > >Yeah, it extracts them at install time. It also compiles the package. > >It sounds like CEDET will need extra care from package.el. That's >fine, but it means package.el changes are needed -- so it will have to >wait a bit until I'm actively hacking package.el again. > >In particular what I understood from your notes is that CEDET can't >use the plain vanilla autoload extraction or byte-compile code. > >FWIW one (implicit) goal of ELPA is not to have Makefiles the like for >pure elisp packages. I mean, for package maintainers I think this >kind of thing is probably needed (to make the packages, for one :), >but generally I don't see the need for this for end users. I think it >is much friendlier to let them just point at a package and have it >start working -- and the fewer host-side dependencies this involves, >the better. > > >For autoload extraction, I think we could easily add an option to >define-package to tell package.el not to do anything. That way a >sophisticated package like CEDET could just supply its own activation >code. > >Byte compilation is trickier. I want package.el to do this so that I >can make it automatically recompile packages when Emacs is upgraded. >I haven't looked at CEDET's build (yet), but I know that some other >packages need some customization: fix the ordering of compilation, >omit a file or two, etc. Would this sort of thing suffice for CEDET? [ ... ] Based on a different request, I checked in a tool that compiles CEDET from w/in Emacs only in cedet-build.el. It only handles the Emacs Lisp part. There are three kinds of targets it will build, including autoload files, grammar files, and general Lisp files. Order is important since the build process uses the tool it's compiling, so compilation bootstrapping is fragile. That build script will likely make it easier for package.el, but it needs to be run in a fresh emacs like this: emacs -q -l cedet-build.el -f cedet-build and after it's built, you really need to exit Emacs so the compiled versions can be loaded for performance reasons. Eric -- Eric Ludlam: er...@si... Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net |