CEDET

My mistake on previous email.

Here the first A is in scope, because bar::xx is in the second A
namespace.  I've updated the scope calculator to find and use the
merged A namespace instead of only the namespace block that bar::xx
shows up in.

If bar had been outside of A, like this:

void A::bar::xx() ...

then it would have worked since A::bar would have used the merged
version of A in the internal searches.

Eric

>>> Ravikiran Rajagopal <ravi.rajagopal@...> seems to think that:
>Hello,
>  The C++ parser does not seem to use namespaces when resolving names for 
>auto-completion. Here is a simple example:
>
>--------------------
>namespace A { class foo { public: void aa(); void bb(); };}
>namespace A { 
>class bar { public: void xx(); public: foo myFoo; };
>void bar::xx()
>{
>  myFoo. // <--- cursor is here after the dot
>}
>}
>--------------------
>
>Using the CVS version of CEDET on Emacs CVS (23.0.60), the analysis finds that 
>the variable "myFoo" is of type "foo", but it cannot find a definition of 
>type "foo" since it does not match "A::foo" as the same "foo" in the 
>declaration of class "bar". Without the "namespace" declarations, the type is 
>parsed correctly and the possible completions are presented. Could someone 
>kindly point me in the right direction to fix this problem? I am an elisp 
>novice (know just enough to muck with my .emacs) but very comfortable with 
>C++; please point me in the direction of documentation if this is known.
>
>Regards,
>Ravi
>

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

>>> andrey-google <buricchio@...> seems to think that:
>Hi, Eric.
>
>[...]
>>   I think this may fail to add any Makefiles for sub-sub projects, or
>> deeper since ede-map-subprojects only does one level.
>>   I added a new fcn ede-map-all-subprojects to try and solve this
>> problem.  I checked this into CVS.  Could you give it a try?
>[...]
>
>I've just tried the function. Cool! I didn't overcome the only
>feature, that the function maps root project too, for which
>ede-subproject-relative-path returns full path. So I've made
>following changes in the code:
>
>ede.el, end of function ede-subproject-relative-path changed to return ""
>instead of full path
>*****
>was: dir)))
>changed: to "")))
>*****
>
>then in ede-pconf.el:
>*****
>(autoconf-set-output
>     (ede-map-all-subprojects this
>      (lambda (sp) 
>        (concat (file-name-as-directory 
>                 (directory-file-name 
>                  (ede-subproject-relative-path sp)))
>                 "Makefile"))))
>*****
>Is it ok?
>Thanks a lot!
  [ ... ]

Good find.  Looking at the relative-path function, it doesn't handle
sub-sub projects either.  I updated it with your patch, and with a
'parent-in' input argument.  This allows the set-output call to pass
in the root that all these things need to be relative to.

I submitted both changes for you to try out.

Eric

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

It's works! CEDET is best! Thank you very much.

Andrey.

[...]
> sub-sub projects either.  I updated it with your patch, and with a
> 'parent-in' input argument.  This allows the set-output call to pass
> in the root that all these things need to be relative to.

> I submitted both changes for you to try out.
[...]

>>> andrey-google <buricchio@...> seems to think that:
>Hi,
>
>For CEDET crew: Thanks a lot for CEDET!
>
>Question: I can not set right options ("Customize Project\Target ...")
>for automake project with subprojects to generate correct AC_OUTPUT by
>EDE. EDE always generates configure.in with default
>AC_OUTPUT(Makefile, [date > stamp-h]) without references to
>subrojects. There is no much good to edit configure.in by hands
>(because of possible regeneration).  Is it possible to setup project
>to generate something like AC_OUTPUT(Makefile subdir1/Makefile
>subdir2/Makefile ...)? Or is there other way to manage EDE automake
>projects with subfolders?
  [ ... ]

It has been many years since I worked with Automake.  Looking through
the code, it looks like `autoconf-set-output' is called from
`ede-proj-configure-synchronize'.  I think each subproject ought to be
applying it's Makefile.  It might be worth using edebug in
`ede-proj-configure-synchronize' to make sure it's doing the right
thing.  It may be passing in the wrong value or something.

Eric

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

Hi Eric,

[ ... ]
> Looking through the code, it looks like `autoconf-set-output' is called from
> `ede-proj-configure-synchronize'.  I think each subproject ought to be
> applying it's Makefile.  It might be worth using edebug in
> `ede-proj-configure-synchronize' to make sure it's doing the right
> thing.  It may be passing in the wrong value or something.
[ ... ]

It seems, that the problem is due to line 65 in ede-pconf.el:
*********
 (autoconf-set-output '("Makefile"))
**********

Is it 'ok' to change the code to following?:
********
 (autoconf-set-output
     (append '("Makefile") 
             (ede-map-subprojects
              this
              (lambda (sp) 
                (concat 
                 (directory-file-name 
                  (ede-subproject-relative-path sp)) 
                 "/Makefile"))))) 
*********
Seems, it works for me. But it may contradict some of EDE principles,
may it? Sorry, I'm "newbie" and quite lame in the subject (and in emacs programming
too).

Thanks,

Andrew.

Hi,

  Thanks for the patch!  The idea is correct.

  I think this may fail to add any Makefiles for sub-sub projects, or
deeper since ede-map-subprojects only does one level.

  I added a new fcn ede-map-all-subprojects to try and solve this
problem.  I checked this into CVS.  Could you give it a try?

Thanks
Eric

>>> andrey-google <buricchio@...> seems to think that:
>Hi Eric,
>
>[ ... ]
>> Looking through the code, it looks like `autoconf-set-output' is called from
>> `ede-proj-configure-synchronize'.  I think each subproject ought to be
>> applying it's Makefile.  It might be worth using edebug in
>> `ede-proj-configure-synchronize' to make sure it's doing the right
>> thing.  It may be passing in the wrong value or something.
>[ ... ]
>
>It seems, that the problem is due to line 65 in ede-pconf.el:
>*********
> (autoconf-set-output '("Makefile"))
>**********
>
>Is it 'ok' to change the code to following?:
>********
> (autoconf-set-output
>     (append '("Makefile") 
>             (ede-map-subprojects
>              this
>              (lambda (sp) 
>                (concat 
>                 (directory-file-name 
>                  (ede-subproject-relative-path sp)) 
>                 "/Makefile"))))) 
>*********
>Seems, it works for me. But it may contradict some of EDE principles,
>may it? Sorry, I'm "newbie" and quite lame in the subject (and in emacs programming
>too).
  [ ... ]

Dear Eric,

"Eric M. Ludlam" <eric@...> writes:

>>>> Patrick Drechsler <patrick@...> seems to think that:
[...]
>>The only line in my init.el concerning cedet is:
>>
>>(load-file "~/.emacs.d/mysitelisp/cedet-1.0beta3b/common/cedet.el")
>
> Version beta3b does not have a cedet-version function, but it does
> have a variable.  The cedet-version function wasn't introduced till a
> bit later.
>
> You may just need to update to a newer version, or to the CVS version.

OK, thank you for the feedback. After updating to cedet-1.0pre4 `M-x
cedet-version' returns:

,----
| CEDET Version:	1.0pre4
|   			Requested	File		Loaded
|   Package		Version		Version		Version
|   ----------------------------------------------------------
|   cedet:		1.0pre4		ok		ok
|   cogre:		0.5		ok		Not Loaded
|   ede:			1.0pre4		ok		ok
|   eieio:		1.0		ok		ok
|   semantic:		2.0pre4		ok		ok
|   speedbar:		1.0.1		ok		ok
|   cedet-contrib:	1.0pre4		ok		Not Loaded
`----

Sorry for not checking and installing the current version before
reporting a fixed bug and wasting your time.

[...]
>>(setq semanticdb-default-save-directory "~/log/semantic.cache")
>
> The save-directory should be a directory, not a file, such as "~/log/"
> or some-such.

The save-directory is actually a directory called
"~/log/semantic.cache/". It works as expected. Admittedly not
predictable from the name..

> Setting it to ~/.semanticdb will be the default in the future.

Sounds better than my solution ;-)

Cheers,

Patrick 
-- 
Christian, n. One who follows the teachings of Christ so long as they
are not inconsistent with a life of sin.

"Eric M. Ludlam" <eric@...> writes:

> I have CC'd the ECB mailing list for the ECB part of this question.

Where do I sign up for sourceforge.net.ecb-devel ?

Clicking on http://ecb.sourceforge.net/ -> "Mailing List" only gives me
the "user list", not the "devel list".

Cheers,

Patrick 
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find." (Terry Pratchett)

>>> Patrick Drechsler <patrick@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> I have CC'd the ECB mailing list for the ECB part of this question.
>
>Where do I sign up for sourceforge.net.ecb-devel ?
>
>Clicking on http://ecb.sourceforge.net/ -> "Mailing List" only gives me
>the "user list", not the "devel list".
  [ ... ]


Hmmm, that might explain why I didn't get my mail echo'd back. :)  You
should probably use the user list.

ERic

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

"Eric M. Ludlam" <eric@...> writes:

>>>> Patrick Drechsler <patrick@...> seems to think that:
>>"Eric M. Ludlam" <eric@...> writes:
>>
>>> I have CC'd the ECB mailing list for the ECB part of this question.
>>
>>Where do I sign up for sourceforge.net.ecb-devel ?
>>
>>Clicking on http://ecb.sourceforge.net/ -> "Mailing List" only gives me
>>the "user list", not the "devel list".
>   [ ... ]
>
>
> Hmmm, that might explain why I didn't get my mail echo'd back. :)  You
> should probably use the user list.

;-) Done.

Cheers,

Patrick
-- 
OS's and GUI's come and go, only Emacs has lasting power.
(Per Abrahamsen)

Hi,

would you like to receive pretest reports on version 1.0pre4? Or is
there a more current CVS version available online? I could not find a
CVS source for cedet on the homepage[1].

Cheers,

Patrick 

Footnotes: 
[1] http://cedet.sourceforge.net

-- 
If it is love that makes the world go round, then it is surely mucus
and slime which facilitate its translational motion.
    (Roger H. Pain)

Hi,

  Right now I'm looking to get the CVS version ready for another
prerelease and want to make sure it builds and installs clean on as
many platforms as possible.  Getting to CVS is from the project page:

http://sourceforge.net/cvs/?group_id=17886

Eric

>>> Patrick Drechsler <patrick@...> seems to think that:
>Hi,
>
>would you like to receive pretest reports on version 1.0pre4? Or is
>there a more current CVS version available online? I could not find a
>CVS source for cedet on the homepage[1].
>
>Cheers,
>
>Patrick 
>
>Footnotes: 
>[1] http://cedet.sourceforge.net
>

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

>>>>> "Eric" == Eric M Ludlam <eric@...> 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

>>> Tom Tromey <tromey@...> seems to think that:
>>>>>> "Eric" == Eric M Ludlam <eric@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

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.

>>> "Lennart Borgman (gmail)" <lennart.borgman@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

Eric M. Ludlam wrote:
>>>> "Lennart Borgman (gmail)" <lennart.borgman@...> 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?

>>> "Lennart Borgman (gmail)" <lennart.borgman@...> seems to think that:
>Eric M. Ludlam wrote:
>>>>> "Lennart Borgman (gmail)" <lennart.borgman@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net

>>> Tom Tromey <tromey@...> seems to think that:
>>>>>> "Eric" == Eric M Ludlam <eric@...> 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:                       eric@...
   Siege: http://www.siege-engine.com          Emacs: http://cedet.sourceforge.net