CEDET

Hi Eric,

>   I did the dumb new user thing, and built w/out reading the INSTALL
> to remind me what I needed to do.  I found semantic-bnf failed for
> need of a newer speedbar.  You can remove the require of speedbar and
> semantic-bnf will build clean.
> 
>   After that, only the eieio things failed to build for me.  This
> could clean up our build process by not having speedbar as a
> dependency at compile time.  I've also set it as my default at work
> and will continue to use it here for a while.

To be sure I correctly understood, I just have to remove (require
'speedbar) at compilation time from semantic-bnf.el.

Do you think I should remove "speedbar" from :aux-packages of the
"tools" target in Project.ede=3F

Also I think we could recommend a directory organization for CEDET.  I
personally keep my CEDET packages organized like in the CVS
repository (for both Emacs and XEmacs), like this:

/my-emacs-stuff
 |
 |-- CEDET
 |   |
 |   +-- cogre
 |   |
 |   +-- common
 |   |
 |   +-- ede
 |   |
 |   +-- eieio
 |   |
 |   +-- semantic
 |   |
 |   \-- speedbar
 |
 +-- JDEE
 |
 \-- others

So the provided Makefiles work quasi out-of-the-box and I rarely
encounter byte-compilation issues :-)

Also I think that's not nonsense to recommend to install a CEDET core
including EIEIO, semantic and speedbar.  Maybe we could even provide
it as a "cedet-core" or "cedet" package downloadable from sourceforge.

What do you think=3F

Thank you very much for your help!

David

Re[2]: [CEDET-devel] Please try Semantic 1.4.1 From: Eric M. Ludlam <eric@si...> - 2002-12-05 12:56 >>> "David PONCE" <David.Ponce@...> seems to think that: >Hi Eric, > >> I did the dumb new user thing, and built w/out reading the INSTALL >> to remind me what I needed to do. I found semantic-bnf failed for >> need of a newer speedbar. You can remove the require of speedbar and >> semantic-bnf will build clean. >> >> After that, only the eieio things failed to build for me. This >> could clean up our build process by not having speedbar as a >> dependency at compile time. I've also set it as my default at work >> and will continue to use it here for a while. > >To be sure I correctly understood, I just have to remove (require >'speedbar) at compilation time from semantic-bnf.el. Yes, that was my experience. It occurred to me later that my environment at work may not be typical as there are random versions of all CEDET tools floating around out there. I should retry on an isolated system. >Do you think I should remove "speedbar" from :aux-packages of the >"tools" target in Project.ede? I think that might be possible. A lot of speedbar setup is such that tools will load and operate while speedbar is not used nor loaded. The requires were originally put in to remove warnings. After thinking about it, Semantic may be using some speedbar macros which would break if we do the above. I think I may rescind my recommendation as too unstable to try at this juncture. >Also I think we could recommend a directory organization for CEDET. I >personally keep my CEDET packages organized like in the CVS >repository (for both Emacs and XEmacs), like this: > >/my-emacs-stuff > | > |-- CEDET > | | > | +-- cogre > | | > | +-- common > | | > | +-- ede > | | > | +-- eieio > | | > | +-- semantic > | | > | \-- speedbar > | > +-- JDEE > | > \-- others > >So the provided Makefiles work quasi out-of-the-box and I rarely >encounter byte-compilation issues :-) > >Also I think that's not nonsense to recommend to install a CEDET core >including EIEIO, semantic and speedbar. Maybe we could even provide >it as a "cedet-core" or "cedet" package downloadable from sourceforge. [ ... ] The JDEE mailing list is awash with discussions on an install program. Perhaps we can recommend this structure for all the tools. One script for CVS, and another for stable or beta packages. Then users would not have to edit the Makefiles anymore. Eric -- Eric Ludlam: zappo@..., eric@... Home: http://www.ludlam.net Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org

Re: [CEDET-devel] Please try Semantic 1.4.1 From: David PONCE <David.Ponce@wa...> - 2002-12-05 14:38 Eric, [...] >>To be sure I correctly understood, I just have to remove (require >>'speedbar) at compilation time from semantic-bnf.el. > > > Yes, that was my experience. It occurred to me later that my > environment at work may not be typical as there are random versions of > all CEDET tools floating around out there. I should retry on an > isolated system. > > >>Do you think I should remove "speedbar" from :aux-packages of the >>"tools" target in Project.ede=3F > > > I think that might be possible. A lot of speedbar setup is such that > tools will load and operate while speedbar is not used nor loaded. > The requires were originally put in to remove warnings. > > After thinking about it, Semantic may be using some speedbar macros > which would break if we do the above. I think I may rescind my > recommendation as too unstable to try at this juncture. [...] I worked a little more on Semantic byte-compilation issues when both the speedbar and eieio are not installed. In that case to safely byte-compile the core of Semantic I had to remove all the `require' statements inside `eval-when-compile' forms. The counterpart is a lot of warnings :-( The files that can't be compiled are: semantic-analyze.el, semantic-cb.el, semantic-chart.el, semanticdb.el, semantic-ia.el, semantic-ia-sb.el. Because their code directly depends on eieio (defclass, defmethod, etc.). So there is two solutions possible: - Always install semantic, eieio and speedbar together (I would recommend it). - Remove the requirements at compile time (and ignore the bunch of compilation warnings). Of course the libraries that depend on eieio will fail to compile if eieio is not installed! And the semanticdb and chart stuff will not be available! > The JDEE mailing list is awash with discussions on an install > program. Perhaps we can recommend this structure for all the tools. > One script for CVS, and another for stable or beta packages. Then > users would not have to edit the Makefiles anymore. Providing a "cedet" package with its own version number (and Project.ede and Makefile), including compatible and up-to-date versions of eieio, semantic and speedbar could be a good solution. It will simplify installation and other packages like JDEE or ECB could just depend on a "cedet" level. Other opinion=3F David

Re: [CEDET-devel] Please try Semantic 1.4.1 From: <ryk@ds...> - 2002-12-05 17:21 DP> Providing a "cedet" package with its own version number (and DP> Project.ede and Makefile), including compatible and up-to-date DP> versions of eieio, semantic and speedbar could be a good solution. It DP> will simplify installation and other packages like JDEE or ECB could DP> just depend on a "cedet" level. DP> DP> Other opinion? Hi David and Eric, I too have been using semantic 1.4.1. I think cedet package idea you suggest would make it much easier for users to install the proper versions of packages. I think it is a great idea.

Re: [CEDET-devel] Please try Semantic 1.4.1 From: David PONCE <David.Ponce@wa...> - 2002-12-09 14:27 Attachments: cedet-setup.el      Hi! > I too have been using semantic 1.4.1. Thanks for your help Richard! I think I will make Semantic 1.4.1 publicly available this week, as soon as my spare time will permit. > I think cedet package idea you suggest would make it much > easier for users to install the proper versions of packages. > I think it is a great idea. Thanks! I thought a little more on that and hacked the attached cedet-setup.el file as a first try to simplify installation of CEDET tools. The goal is to provide a CEDET distribution in a tarball, unpack it at a chosen path, and just load the cedet-setup.el file from the [X]Emacs startup file to automagically setup a working CEDET environment ;-) cedet-setup uses the `inversion' library to determine if it has to hack the `load-path', and does nothing when it finds a more recent version of a CEDET package in the current load path. Maybe a better design would be to have an equivalent cedet-setup.el for each individual package that would be run by the main cedet-setup.el. Thus each package would be easily installed either alone or when part of the global cedet distro. What do you think=3F David

Re[2]: [CEDET-devel] Please try Semantic 1.4.1 From: Eric M. Ludlam <eric@si...> - 2002-12-09 17:59 >>> "David PONCE" <David.Ponce@...> seems to think that: >Hi! > >> I too have been using semantic 1.4.1. > >Thanks for your help Richard! I think I will make Semantic 1.4.1 >publicly available this week, as soon as my spare time will permit. > >> I think cedet package idea you suggest would make it much >> easier for users to install the proper versions of packages. >> I think it is a great idea. > >Thanks! > >I thought a little more on that and hacked the attached >cedet-setup.el file as a first try to simplify installation of CEDET >tools. > >The goal is to provide a CEDET distribution in a tarball, unpack it at >a chosen path, and just load the cedet-setup.el file from the [X]Emacs >startup file to automagically setup a working CEDET environment ;-) > >cedet-setup uses the `inversion' library to determine if it has to >hack the `load-path', and does nothing when it finds a more recent >version of a CEDET package in the current load path. > >Maybe a better design would be to have an equivalent cedet-setup.el >for each individual package that would be run by the main >cedet-setup.el. Thus each package would be easily installed either >alone or when part of the global cedet distro. [ ... ] This is a nifty idea. Your function that fetches a version number from a file without loading it would be a good addition to inversion. it might be nice to give "cedet" a version number. That way JDE or ECB could just depend on a specific combination of packages. Since this is about loading the cedet packages, perhaps a -load extension, as does semantic, would be appropriate. Then again, as does the JDE, you could just call it cedet.el, and then it's version number could be queried by inversion. Eric -- Eric Ludlam: zappo@..., eric@... Home: http://www.ludlam.net Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org

Re: [CEDET-devel] Please try Semantic 1.4.1 From: David PONCE <David.Ponce@wa...> - 2002-12-10 16:32 Attachments: cedet.el      inversion.patch      Hi Eric, [...] > This is a nifty idea. Your function that fetches a version number > from a file without loading it would be a good addition to > inversion. Thanks! Attached you will find a patch that adds `inversion-find-version' to inversion.el. It also contains some minor fixes and I commented out the call to `inversion-upgrade-package' that try to upgrade Semantic each time inversion is loaded! > it might be nice to give "cedet" a version number. That way JDE or > ECB could just depend on a specific combination of packages. > > Since this is about loading the cedet packages, perhaps a -load > extension, as does semantic, would be appropriate. Then again, as > does the JDE, you could just call it cedet.el, and then it's version > number could be queried by inversion. These are good remarks ;-) I attached a new version renamed cedet.el with a `cedet-version' 1.0! It also uses `inversion-find-version' from the patch above. What do you think=3F David

Re[2]: [CEDET-devel] Please try Semantic 1.4.1 From: Eric M. Ludlam <eric@si...> - 2002-12-11 03:54 >>> "David PONCE" <David.Ponce@...> seems to think that: >Hi Eric, > >[...] >> This is a nifty idea. Your function that fetches a version number >> from a file without loading it would be a good addition to >> inversion. > >Thanks! > >Attached you will find a patch that adds `inversion-find-version' to >inversion.el. It also contains some minor fixes and I commented out >the call to `inversion-upgrade-package' that try to upgrade Semantic >each time inversion is loaded! That's great. I'd be tempted to have the function name more explicitly say that it doesn't load the file, perhaps `inversion-find-version-in-file' or `inversion-find-version-no-load' or some such. Otherwise, I think it's great to check in. >> it might be nice to give "cedet" a version number. That way JDE or >> ECB could just depend on a specific combination of packages. >> >> Since this is about loading the cedet packages, perhaps a -load >> extension, as does semantic, would be appropriate. Then again, as >> does the JDE, you could just call it cedet.el, and then it's version >> number could be queried by inversion. > >These are good remarks ;-) I attached a new version renamed cedet.el >with a `cedet-version' 1.0! It also uses `inversion-find-version' >from the patch above. [ ... ] It might also make sense to pull out parts of `inversion-test' so that the decoded version numbers can be passed in, eliminating the `cedet-test' mock-package. I can think on this after you check in your changes. I'm tempted to also recommend that we put `cedet-add-to-load-path' into inversion, or someplace useful. Mostly so that `cedet.el' becomes very simple. Simple good, especially if we put lots of configuration hints into it, such as `semantic-turn-useful-things-on'. Thanks! Eric -- Eric Ludlam: zappo@..., eric@... Home: http://www.ludlam.net Siege: http://www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org

Re: [CEDET-devel] Please try Semantic 1.4.1 From: David PONCE <David.Ponce@wa...> - 2002-12-11 09:03 Hi Eric, [...] > That's great. I'd be tempted to have the function name more > explicitly say that it doesn't load the file, perhaps > `inversion-find-version-in-file' or `inversion-find-version-no-load' > or some such. Otherwise, I think it's great to check in. Thanks! I checked the changes in. What do you think about `inversion-find-file-version', or `inversion-locate-package-version' as the function uses `locate-file' to find the main package file=3F [...] > It might also make sense to pull out parts of `inversion-test' so > that the decoded version numbers can be passed in, eliminating the > `cedet-test' mock-package. I can think on this after you check in > your changes. Yes that would be great! > I'm tempted to also recommend that we put `cedet-add-to-load-path' > into inversion, or someplace useful. Mostly so that `cedet.el' > becomes very simple. Simple good, especially if we put lots of > configuration hints into it, such as > `semantic-turn-useful-things-on'. That's a great idea to have inversion providing all the necessary tools to install packages and manage dependencies! I completely agree with you! Thanks! David

Re: [CEDET-devel] Please try Semantic 1.4.1 From: David PONCE <David.Ponce@wa...> - 2002-12-11 15:09 Attachments: inversion.patch      Eric, Following your good suggestion: > It might also make sense to pull out parts of `inversion-test' so > that the decoded version numbers can be passed in, eliminating the > `cedet-test' mock-package. I can think on this after you check in > your changes. I made the attached patch to inversion.el, that add the new function `inversion-check-version' to directly check versions (as string or encoded). `inversion-test' uses that function and it is easy to make `cedet-add-to-load-path' use it too! What do you think=3F David P.S.: I finally released Semantic 1.4.1 :-)

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