CEDET

Hi all,

  To the best of my knowledge, I think I've fixed all the build,
utest, and itest issues that showed up in the last pre-release, and
checked those changes into CVS.  If I somehow missed one of your
reports, please try the CVS version and remind me, as I only have
web-site related TODO items left.

  There are a couple items on the wiki that I have no repro steps for.
One is related to a Cogre failure.  If you had this failure, please
let me know more, or try CVS to see if it is still there.

  If I don't hear anything new, I'm going to try putting together
another release with a wider notification announcement.

  Lastly, I'd like to thank everyone who tried out the pre-release and
posted information about your platform, or worked through different
problems with me.  That effort is appreciated, and has greatly
improved CEDET's stability these past two weeks.


Thanks!

Eric

-- 
          Eric Ludlam:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Re: [CEDET-devel] Pre-release status question From: Alastair Rankine <arsptr@in...> - 2009-03-13 00:17 Eric M. Ludlam wrote: > Hi all, > > To the best of my knowledge, I think I've fixed all the build, > utest, and itest issues that showed up in the last pre-release, and > checked those changes into CVS. If I somehow missed one of your > reports, please try the CVS version and remind me, as I only have > web-site related TODO items left. > > There are a couple items on the wiki that I have no repro steps for. > One is related to a Cogre failure. If you had this failure, please > let me know more, or try CVS to see if it is still there. > Eric, >From my perspective there are a couple of problems with cedet right now, I haven't had time to track them down much further, but fortunately (or not?) they seem to be reproduced by others on this list. Firstly I am seeing the "Save error: listp" problem, as reported by Hannes Janetzek. http://thread.gmane.org/gmane.emacs.cedet/3283 Secondly I am still seeing the problem in the cedet integration tests relating to the constructor in srecode-generated c++ classes. Also reported by someone else, can't remember now. http://thread.gmane.org/gmane.emacs.cedet/3066/focus=3090 Again I apologise for not having the time to track either of these down, but just wanted to let you know these are the issues I'm seeing ATM.

Re: [CEDET-devel] Pre-release status question From: Eric M. Ludlam <eric@si...> - 2009-03-13 02:18 >>> Alastair Rankine <arsptr@...> seems to think that: >Eric M. Ludlam wrote: >> Hi all, >> >> To the best of my knowledge, I think I've fixed all the build, >> utest, and itest issues that showed up in the last pre-release, and >> checked those changes into CVS. If I somehow missed one of your >> reports, please try the CVS version and remind me, as I only have >> web-site related TODO items left. >> >> There are a couple items on the wiki that I have no repro steps for. >> One is related to a Cogre failure. If you had this failure, please >> let me know more, or try CVS to see if it is still there. >> > >Eric, > >>From my perspective there are a couple of problems with cedet right now, >I haven't had time to track them down much further, but fortunately (or >not?) they seem to be reproduced by others on this list. > >Firstly I am seeing the "Save error: listp" problem, as reported by >Hannes Janetzek. http://thread.gmane.org/gmane.emacs.cedet/3283 Hi, I've fiddled with the header file he sent me many times, but I cannot seem to reproduce the problem. I checked in a small change to try to produce additional output identifying the problem table. If you set `semanticdb-data-debug-on-write-error' to t, then it should show a data-debugger on the offending table object. This may allow you to find the offending data structure, and perhaps you can share the header file. If not, you could visit that file, and force a reparse to see if that helps. If so, then there is probably some sort of secret incremental parser bug. >Secondly I am still seeing the problem in the cedet integration tests >relating to the constructor in srecode-generated c++ classes. Also >reported by someone else, can't remember now. >http://thread.gmane.org/gmane.emacs.cedet/3066/focus=3090 > >Again I apologise for not having the time to track either of these down, >but just wanted to let you know these are the issues I'm seeing ATM. I remember this, but I've been at a loss as to why you are getting the wrong templates during code insertion. I was thinking I'd have to implement some sort of debugger for template insertion to solve it. I suspect that is a big project. If anyone else has ideas, I'd like to hear them. Eric -- Eric Ludlam: eric@... Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

Re: [CEDET-devel] Pre-release status question From: Bruce Stephens Attachments: Message as HTML      pem.h

Re: [CEDET-devel] Pre-release status question From: David Engster <deng@ra...> - 2009-03-13 13:10 "Eric M. Ludlam" <eric@...> writes: >>>> Alastair Rankine <arsptr@...> seems to think that: >>Secondly I am still seeing the problem in the cedet integration tests >>relating to the constructor in srecode-generated c++ classes. Also >>reported by someone else, can't remember now. >>http://thread.gmane.org/gmane.emacs.cedet/3066/focus=3090 >> >>Again I apologise for not having the time to track either of these down, >>but just wanted to let you know these are the issues I'm seeing ATM. > > I remember this, but I've been at a loss as to why you are getting the > wrong templates during code insertion. I was thinking I'd have to > implement some sort of debugger for template insertion to solve it. I > suspect that is a big project. > > If anyone else has ideas, I'd like to hear them. I reported that issue for Mac OS X, but I now also saw it on Linux (Ubuntu 8.10). I investigated further, and it seems to be a timing problem with 'autoload, which makes it a bit difficult to debug. Here's what I observed so far: The problem ist that foo.hh is not properly set up for parsing, since semantic-new-buffer-fcn is called with an empty semantic--parse-table. This problem does not only happen with the integration test, but always when I start Emacs with the minimal CEDET setup (i.e. with loaded common/cedet.el and minimum features enabled), and open a file which uses C++-mode (e.g foo.hh). It seems that in this case 'semantic-c-by--install-parser' is called *after* 'semantic-new-buffer-fcn' has already run from the file-load-hook. Therefore, when 'semantic-new-buffer-fcn' is run on foo.hh, the 'semantic--parse-table' is empty, and hence the buffer is not properly set up for parsing. This again seems to lead to the wrong templates being inserted. If I do a (require 'semantic-c) before loading the first file, everything works fine. Now, the question is why this happens on a few machines only. I observed that on that Linux system in question, the semantic-c autoload is pretty busy with parsing configc++.h; in fact, there are *two* configc++.h files which are parsed, namely /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h I included some debug messages in the involved functions and also in the hooks, and here's the output when I create a new file foo.hh on a fresh Emacs -q with minimal CEDET setup: --8<---------------cut here---------------start------------->8--- (New file) Loading cc-mode...done DEBUG: Execute c++-mode-hook Loading /home/david/cedet/semantic/bovine/semantic-c.el (source)... Loading ring...done Loading semantic-dep...done Loading semantic-gcc...done DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h. Loading semanticdb-file...done DEBUG: Execute c++-mode-hook Loading /home/david/cedet/semantic/bovine/semantic-c.el (source)... DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h. Loading /home/david/cedet/semantic/bovine/semantic-c.el (source)...done DEBUG: semantic-c-by: installed parser for c++config.h. DEBUG: Execute find-file-hook DEBUG: semantic-new-buffer-fcn: called on buffer c++config.h. DEBUG: semantic-new-buffer-fcn: buffer c++config.h was set up for parsing. DEBUG: semantic-new-buffer-fcn: called on buffer foo.hh. DEBUG: semantic-new-buffer-fcn: buffer foo.hh has empty parse table. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h. DEBUG: semantic-c-reset-preprocessor-symbol-map: Getting file-table-object for /usr/include/c++/4.3.2/i486-linux-gnu/bits/c++config.h. Loading /home/david/cedet/semantic/bovine/semantic-c.el (source)...done DEBUG: semantic-c-by: installed parser for foo.hh. DEBUG: Execute find-file-hook --8<---------------cut here---------------end--------------->8--- You can see that semantic-new-buffer-fcn is called before the parse table is installed. Here's the same output when doing this with an already 'required' semantic-c: --8<---------------cut here---------------start------------->8--- (New file) DEBUG: Execute c++-mode-hook DEBUG: semantic-c-by: installed parser for foo.hh. DEBUG: Execute find-file-hook DEBUG: semantic-new-buffer-fcn: called on buffer foo.hh. DEBUG: semantic-new-buffer-fcn: buffer foo.hh was set up for parsing. --8<---------------cut here---------------end--------------->8--- Regards, David

Re: [CEDET-devel] Pre-release status question From: David Engster <deng@ra...> - 2009-03-13 14:00 "Eric M. Ludlam" <eric@...> writes: > If I somehow missed one of your reports, please try the CVS version > and remind me, as I only have web-site related TODO items left. I think a new error has cropped up. It seems the 'cd src;make' has changed to 'make -C src', but this fails for me: make make -C src make[1]: Entering directory `/private/tmp/CEDET_INTEG/edeproj/src' for loadpath in . ../../../../Users/david/cedet/common/ ../../../../Users/david/cedet/eieio/; do \ echo "(add-to-list 'load-path \"$loadpath\")" >> Auto-compile-script; \ done; "emacs" -batch --no-site-file -l Auto-compile-script -f cedet-batch-update-autoloads loaddefs.el . Cannot open load file: cedet-autogen make[1]: *** [Auto] Error 255 make[1]: Leaving directory `/private/tmp/CEDET_INTEG/edeproj/src' make: *** [Src] Error 2 Doing 'cd src;make' in /tmp/CEDET_INTEG/edeproj works. This is all with GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. -David

Re: [CEDET-devel] Pre-release status question From: Eric M. Ludlam <eric@si...> - 2009-03-13 15:54 >>> David Engster <deng@...> seems to think that: [ ... ] >I reported that issue for Mac OS X, but I now also saw it on Linux >(Ubuntu 8.10). I investigated further, and it seems to be a timing >problem with 'autoload, which makes it a bit difficult to debug. > >Here's what I observed so far: [ ... ] Hi David. That is some excellent sleuthing. I will investigate this in more detail as soon as I can. I wonder if semantic-c is perhaps erroring out when it loads the first time, and that might cause a problem? Eric -- Eric Ludlam: eric@... Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

[CEDET-devel] Installation failure on GNU Emacs 23.0.91.1 (i386-mingw-nt5.1.2600) of 2009-02-26 From: daveluciffer <daveluciffer@gm...> - 2009-03-13 16:07 Hi Eric, I have a installation failure with my GNU Emacs (GNU Emacs 23.0.91.1 (i386-mingw-nt5.1.2600) of 2009-02-26 ) build on MS Windows, with cygwin installed. The emacs build was retrieved from the project Emacs W32 (http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl) I tried the build within Emacs option with cedet-build.el, following the instruction: ";; Eval this buffer and then start compilation: ;; ;; M-x eval-buffer ;; M-x cedet-build-in-default-emacs" The installation failed, and the message shows: "For information about GNU Emacs and the GNU system, type C-h C-a. Loading d:/downloads/software/Emacs/cedet/cedet-1.0pre6/common/inversion.el (source)...done Loading d:/downloads/software/Emacs/cedet/cedet-1.0pre6/eieio/eieio-comp.el (source)...done Loading d:/downloads/software/Emacs/cedet/cedet-1.0pre6/common/cedet-autogen.el (source)...done Saving file d:/downloads/software/Emacs/cedet/cedet-1.0pre6/ede/ede-loaddefs.el... Updating header...done Wrote d:/downloads/software/Emacs/cedet/cedet-1.0pre6/ede/ede-loaddefs.el Saving file d:/downloads/software/Emacs/cedet/cedet-1.0pre6/semantic/semantic-loaddefs.el... Updating header...done Wrote d:/downloads/software/Emacs/cedet/cedet-1.0pre6/semantic/semantic-loaddefs.el Saving file d:/downloads/software/Emacs/cedet/cedet-1.0pre6/srecode/srecode-loaddefs.el... Updating header...done Wrote d:/downloads/software/Emacs/cedet/cedet-1.0pre6/srecode/srecode-loaddefs.el Loading d:/downloads/software/Emacs/cedet/cedet-1.0pre6/common/cedet.el (source)... Outdated eieio 1.0 shadowed to meet minimum version 1.2 Outdated semantic 2.0pre4 shadowed to meet minimum version 2.0pre6 Outdated ede 1.0pre4 shadowed to meet minimum version 1.0pre6 Outdated speedbar 1.0.1 shadowed to meet minimum version 1.0.2 Outdated cogre 0.5 shadowed to meet minimum version 0.7 Outdated cedet-contrib 1.0pre4 shadowed to meet minimum version 1.0pre6 Setting up CEDET packages... Invalid function: define-obsolete-variable-alias Symbol's function definition is void: ede-project-autoload Setting up CEDET packages...done Loading d:/downloads/software/Emacs/cedet/cedet-1.0pre6/common/cedet.el (source)...done save-excursion: Symbol's function definition is void: global-ede-mode" I hope this info would be helpful to solve this kind of problems. Bests, Da Zhang Eric M. Ludlam wrote: > Hi all, > > To the best of my knowledge, I think I've fixed all the build, > utest, and itest issues that showed up in the last pre-release, and > checked those changes into CVS. If I somehow missed one of your > reports, please try the CVS version and remind me, as I only have > web-site related TODO items left. > > There are a couple items on the wiki that I have no repro steps for. > One is related to a Cogre failure. If you had this failure, please > let me know more, or try CVS to see if it is still there. > > If I don't hear anything new, I'm going to try putting together > another release with a wider notification announcement. > > Lastly, I'd like to thank everyone who tried out the pre-release and > posted information about your platform, or worked through different > problems with me. That effort is appreciated, and has greatly > improved CEDET's stability these past two weeks. > > > Thanks! > > Eric > >

Re: [CEDET-devel] Installation failure on GNU Emacs 23.0.91.1 (i386-mingw-nt5.1.2600) of 2009-02-26 From: Lennart Borgman <lennart.borgman@gm...> - 2009-03-13 16:15 Dave, I guess this is the unpatched version? On Fri, Mar 13, 2009 at 5:07 PM, daveluciffer <daveluciffer@...> wrote: > Hi Eric, > > I have a installation failure with my GNU Emacs (GNU Emacs 23.0.91.1 > (i386-mingw-nt5.1.2600) of 2009-02-26 ) build on MS Windows, with cygwin > installed. > The emacs build was retrieved from the project Emacs W32 > (http://ourcomments.org/cgi-bin/emacsw32-dl-latest.pl) > > I tried the build within Emacs option with cedet-build.el, following the > instruction: > ";;     Eval this buffer and then start compilation: > ;; > ;;     M-x eval-buffer > ;;     M-x cedet-build-in-default-emacs" > > The installation failed, and the message shows:

Re: [CEDET-devel] Pre-release status question From: John Ridgway <john@ja...> - 2009-03-13 16:18 Attachments: cedet.log      Message as HTML      In my continuing quest to package CEDET for Fink, I downloaded the current CVS version; then ran "make dist" to create the .info files, and got the errors included in the attached log. Is there something I should have done rather than "make dist", since what I wanted was the version to be distributed? Peace - John

Re: [CEDET-devel] Pre-release status question From: David Engster <deng@ra...> - 2009-03-14 00:48 "Eric M. Ludlam" <eric@...> writes: >>>> David Engster <deng@...> seems to think that: > [ ... ] >>I reported that issue for Mac OS X, but I now also saw it on Linux >>(Ubuntu 8.10). I investigated further, and it seems to be a timing >>problem with 'autoload, which makes it a bit difficult to debug. >> >>Here's what I observed so far: > [ ... ] > > Hi David. That is some excellent sleuthing. I will investigate this > in more detail as soon as I can. I wonder if semantic-c is perhaps > erroring out when it loads the first time, and that might cause a > problem? Maybe. I'm pretty sure by now that the problem lies in the two c++config.h files being parsed. On my Debian machine at home (gcc version 4.3.3), I now get the following error when calling semantic-default-c-setup: Debugger entered--Lisp error: (void-variable semanticdb-current-table) semanticdb-create-table-for-file-not-in-buffer("/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h") semanticdb-file-table-object("/usr/include/c++/4.3.3/i486-linux-gnu/bits/c++config.h") semantic-c-reset-preprocessor-symbol-map() (semantic-default-c-setup) eval((semantic-default-c-setup)) Note the different paths ("4.3.3" and "4.3"). semantic-gcc-setup puts "/usr/include/c++/4.3/i486-linux-gnu/bits/c++config.h" "/usr/include/c++/4.3.3/i486-linux-gnu/bits/c++config.h" in semantic-lex-c-preprocessor-symbol-file, and both files are the same on my machine. If I modify the function to just include the latter, everything works fine. I guess that would make sense in any case, and I'd also assume there's a chance that this wouldfix the bug with the foo.hh buffer not being correctly setup (I can't test at the moment). -David

Re: [CEDET-devel] Pre-release status question From: Eric M. Ludlam <eric@si...> - 2009-03-14 15:30 >>> David Engster <deng@...> seems to think that: >"Eric M. Ludlam" <eric@...> writes: >>>>> Alastair Rankine <arsptr@...> seems to think that: >>>Secondly I am still seeing the problem in the cedet integration tests >>>relating to the constructor in srecode-generated c++ classes. Also >>>reported by someone else, can't remember now. >>>http://thread.gmane.org/gmane.emacs.cedet/3066/focus=3090 >>> >>>Again I apologise for not having the time to track either of these down, >>>but just wanted to let you know these are the issues I'm seeing ATM. >> >> I remember this, but I've been at a loss as to why you are getting the >> wrong templates during code insertion. I was thinking I'd have to >> implement some sort of debugger for template insertion to solve it. I >> suspect that is a big project. >> >> If anyone else has ideas, I'd like to hear them. > >I reported that issue for Mac OS X, but I now also saw it on Linux >(Ubuntu 8.10). I investigated further, and it seems to be a timing >problem with 'autoload, which makes it a bit difficult to debug. > >Here's what I observed so far: > [ ... ] Hi, Based your stacks and logs, I made a range of changes in a few locations to try and make your issues more discoverable and robust. Here are the changes which I have checked in: semantic-c.el - Prevent recursion in semantic-c-reset-preprocessor-symbol-map, and disable out-of-buffer tag table creation. (ie - ctags interface.) Also be robust to semanticdb being off in above fcn. srecode-maps.el - Allow the srecode-map-save-file so it can be nil. (ie, disable any save files, or creation of save files.) cedet-utest.el cit-load.el Disable semanticdb saving or reading tag tables to/from disk. Disable srecode from saving/loading maps. semanticdb-mode.el Add autoload cookie on the unbound variable you found. The net effects of these changes is that the tests now all run CEDET in a bootstrap mode, as if the user had never used CEDET before. This should eliminate any questions about bad cache files. (I hope anyway.) Then there are the changes to semantic-c nd semanticdb-mode that I am guessing fix your specific problem. Let me know if it works for you. Thanks Eric -- Eric Ludlam: eric@... Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

Re: [CEDET-devel] Pre-release status question From: David Engster <deng@ra...> - 2009-03-14 19:04 "Eric M. Ludlam" <eric@...> writes: > Based your stacks and logs, I made a range of changes in a few > locations to try and make your issues more discoverable and robust. > Here are the changes which I have checked in: [...] > The net effects of these changes is that the tests now all run CEDET > in a bootstrap mode, as if the user had never used CEDET before. This > should eliminate any questions about bad cache files. (I hope > anyway.) > > Then there are the changes to semantic-c nd semanticdb-mode that I am > guessing fix your specific problem. > > Let me know if it works for you. Your changes did the trick! So far I tested with the Debian and Ubuntu machines which had problems, and the integration test now runs fine. One other quick remark on your original post: > There are a couple items on the wiki that I have no repro steps for. >One is related to a Cogre failure. If you had this failure, please >let me know more, or try CVS to see if it is still there. If you're talking about this one: Running cogre: uml ... ERROR: (error "Method semanticdb-get-tags called on nil") failed I also had this one, but it was due to the minimum features not being enabled. Regards, David

Re: [CEDET-devel] Pre-release status question From: Eric M. Ludlam <eric@si...> - 2009-03-14 21:44 >>> David Engster <deng@...> seems to think that: >"Eric M. Ludlam" <eric@...> writes: >> Based your stacks and logs, I made a range of changes in a few >> locations to try and make your issues more discoverable and robust. >> Here are the changes which I have checked in: > >[...] > >> The net effects of these changes is that the tests now all run CEDET >> in a bootstrap mode, as if the user had never used CEDET before. This >> should eliminate any questions about bad cache files. (I hope >> anyway.) >> >> Then there are the changes to semantic-c nd semanticdb-mode that I am >> guessing fix your specific problem. >> >> Let me know if it works for you. > >Your changes did the trick! So far I tested with the Debian and Ubuntu >machines which had problems, and the integration test now runs >fine. Great! Thanks for checking. >One other quick remark on your original post: > >> There are a couple items on the wiki that I have no repro steps for. >>One is related to a Cogre failure. If you had this failure, please >>let me know more, or try CVS to see if it is still there. > >If you're talking about this one: > >Running cogre: uml ... ERROR: (error "Method semanticdb-get-tags called >on nil") failed > >I also had this one, but it was due to the minimum features not being >enabled. [ ... ] Also good news. Thanks. Eric -- Eric Ludlam: eric@... Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

Re: [CEDET-devel] Pre-release status question From: Eric M. Ludlam <eric@si...> - 2009-03-14 23:23 >>> Bruce Stephens <bruce+cedet@...> seems to think that: >I find this points to /usr/include/openssl/pem.h which I attach (from >Debian's libssl-dev, 0.9.8g-15, in case you need the other headers). > >If I use semantic-show-unmatched-syntax-mode, then line 74 onwards is >underlined (so the 'extern "C" {' is apparently not matched). This >header is loaded in c-mode. (I confess this doesn't feel likely: this >is a common enough pattern in C headers, so surely something more >complex is screwing things up.) Thanks for that file. The problem was thankfully not the extern "C". When an extern "C" is encountered, it recursively parses into it. What happened was that the macros in pem.c caused my pre-processor to freak out. The error is caught by the parsing recurse, and shows up as a bad token, which caused the whole thing to be marked unappeasable. I've narrowed it down to some recursive macros, but I don't have a solution yet. Eric -- Eric Ludlam: eric@... Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

Re: [CEDET-devel] Pre-release status question From: Eric M. Ludlam <eric@si...> - 2009-03-15 02:54 >>> Bruce Stephens <bruce+cedet@...> seems to think that: >I find this points to /usr/include/openssl/pem.h which I attach (from >Debian's libssl-dev, 0.9.8g-15, in case you need the other headers). > >If I use semantic-show-unmatched-syntax-mode, then line 74 onwards is >underlined (so the 'extern "C" {' is apparently not matched). This >header is loaded in c-mode. (I confess this doesn't feel likely: this >is a common enough pattern in C headers, so surely something more >complex is screwing things up.) I finally found the core problem. Macro arguments were not implemented in a way that allowed scoping, which eventually caused a recursion failure. I added the ability to push/pop symbols into the macro table for arguments, and now your header parses for me. Changes are in CVS now. Eric -- Eric Ludlam: eric@... Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

Re: [CEDET-devel] Pre-release status question From: Eric M. Ludlam <eric@si...> - 2009-03-15 02:56 Dear cedet-devel mailing list; The use of -C was a recent patch. I'm interested in any recommendations for the right way to cd and recurse using make that would allow the most compatibility. Thanks Eric >>> David Engster <deng@...> seems to think that: >"Eric M. Ludlam" <eric@...> writes: >> If I somehow missed one of your reports, please try the CVS version >> and remind me, as I only have web-site related TODO items left. > >I think a new error has cropped up. It seems the 'cd src;make' has >changed to 'make -C src', but this fails for me: > >make >make -C src >make[1]: Entering directory `/private/tmp/CEDET_INTEG/edeproj/src' >for loadpath in . ../../../../Users/david/cedet/common/ ../../../../Users/david/cedet/eieio/; do \ > echo "(add-to-list 'load-path \"$loadpath\")" >> Auto-compile-script; \ > done; >"emacs" -batch --no-site-file -l Auto-compile-script -f cedet-batch-update-autoloads loaddefs.el . >Cannot open load file: cedet-autogen >make[1]: *** [Auto] Error 255 >make[1]: Leaving directory `/private/tmp/CEDET_INTEG/edeproj/src' >make: *** [Src] Error 2 > >Doing 'cd src;make' in /tmp/CEDET_INTEG/edeproj works. This is all with > >GNU Make 3.81 >Copyright (C) 2006 Free Software Foundation, Inc. [ ... ] -- Eric Ludlam: eric@... Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

Re: [CEDET-devel] Pre-release status question From: David Engster <deng@ra...> - 2009-03-16 13:26 "Eric M. Ludlam" <eric@...> writes: > The use of -C was a recent patch. I'm interested in any > recommendations for the right way to cd and recurse using make that > would allow the most compatibility. "make -C src" and "cd src;make" should be equivalent. The problem I had stems from another OS X speciality: /tmp is a symbolic link to /private/tmp. Now, if you do "make -C src", then the current directory is expanded to "/private/tmp/CEDET_INTEG/edeproj/src", but if you do "cd src;make", it is still "/tmp/CEDET_INTEG/edeproj/src", which explains why the relative pathname generated by EDE worked only for the latter... The following patch fixed that for me: --8<---------------cut here---------------start------------->8--- Index: ede-proj-elisp.el =================================================================== RCS file: /cvsroot/cedet/cedet/ede/ede-proj-elisp.el,v retrieving revision 1.36 diff -u -r1.36 ede-proj-elisp.el --- ede-proj-elisp.el 24 Feb 2009 00:46:25 -0000 1.36 +++ ede-proj-elisp.el 16 Mar 2009 13:12:18 -0000 @@ -106,7 +106,7 @@ (while packages (or (setq ldir (locate-library (car packages))) (error "Cannot find package %s" (car packages))) - (setq paths (cons (file-relative-name (file-name-directory ldir)) + (setq paths (cons (file-relative-name (file-name-directory ldir) (file-truename ".")) paths) packages (cdr packages))) paths)) --8<---------------cut here---------------end--------------->8--- Regards, David

Re: [CEDET-devel] Pre-release status question From: Eric M. Ludlam <eric@si...> - 2009-03-17 01:54 Hi David, I missed what was really going on in your previous message. Thanks for the patch, it made things clear. I checked in something using a different tact. Instead I check to see of the package in question is too far away; ie, lots of ".." in the relative path. If so, I don't use a relative path. That would fix miscellaneous issues like this, and make things more clear in general on systems that don't have the same aliasing. Thanks Eric >>> David Engster <deng@...> seems to think that: >"Eric M. Ludlam" <eric@...> writes: >> The use of -C was a recent patch. I'm interested in any >> recommendations for the right way to cd and recurse using make that >> would allow the most compatibility. > >"make -C src" and "cd src;make" should be equivalent. The problem I had >stems from another OS X speciality: /tmp is a symbolic link to >/private/tmp. > >Now, if you do "make -C src", then the current directory is expanded to >"/private/tmp/CEDET_INTEG/edeproj/src", but if you do "cd src;make", it >is still "/tmp/CEDET_INTEG/edeproj/src", which explains why the relative >pathname generated by EDE worked only for the latter... > >The following patch fixed that for me: > >--8<---------------cut here---------------start------------->8--- >Index: ede-proj-elisp.el >=================================================================== >RCS file: /cvsroot/cedet/cedet/ede/ede-proj-elisp.el,v >retrieving revision 1.36 >diff -u -r1.36 ede-proj-elisp.el >--- ede-proj-elisp.el 24 Feb 2009 00:46:25 -0000 1.36 >+++ ede-proj-elisp.el 16 Mar 2009 13:12:18 -0000 >@@ -106,7 +106,7 @@ > (while packages > (or (setq ldir (locate-library (car packages))) > (error "Cannot find package %s" (car packages))) >- (setq paths (cons (file-relative-name (file-name-directory ldir)) >+ (setq paths (cons (file-relative-name (file-name-directory ldir) (file-truename ".")) > paths) > packages (cdr packages))) > paths)) >--8<---------------cut here---------------end--------------->8--- [ ... ] -- Eric Ludlam: eric@... Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net

Re: [CEDET-devel] Pre-release status question From: Bruce Stephens "Eric M. Ludlam" <eric@...> writes: [...] > I finally found the core problem. Macro arguments were not > implemented in a way that allowed scoping, which eventually caused a > recursion failure. > > I added the ability to push/pop symbols into the macro table for > arguments, and now your header parses for me. > > Changes are in CVS now. It works for me. [...]

1 message has been excluded from this view by a project administrator.