CEDET merge

[seewhydee]

I have merged most of the CEDET branch into the trunk.  You may need to
bootstrap; please let me know if there are any build failures.

I have done what I can to clean up CEDET to conform to Emacs standards;
if you see anything I missed, please go ahead and make the change.

Currently, the interface to Semantic is via "M-x semantic-mode", and to
EDE via "M-x global-ede-mode"; these should install a "Development" menu
on the menu bar that can be used to enable further features.
Suggestions about improving this interface, and the CEDET integration in
general, are welcome.

(If you want to make bigger changes to the internals of CEDET itself,
please discuss first, because we need to coordinate that kind of change
with upstream.)

[Ulrich Mueller-2]

>>>>> On Mon, 28 Sep 2009, Chong Yidong wrote:

> I have merged most of the CEDET branch into the trunk. You may need
> to bootstrap; please let me know if there are any build failures.

I've tried to byte-compile some packages like company-mode [1] and
JDE [2] with the CEDET included in Emacs, and they fail because some
files that they require have a different name now. For example:

   In toplevel form:
   company-semantic.el:21:1:Error: Cannot open load file: semantic-ia

Was this renaming of files really necessary? It breaks backwards
compatibility and imposes additional work on package authors and
distros.

Ulrich

[1] http://nschum.de/src/emacs/company-mode/
[2] http://jdee.sourceforge.net/

[Eli Zaretskii]

> From: Chong Yidong <cyd@...>
> Date: Mon, 28 Sep 2009 11:31:51 -0400
>
> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

Thanks.  I suggest to update ldefs-boot.el.

[seewhydee]

Ulrich Mueller <ulm@...> writes:

> Was this renaming of files really necessary? It breaks backwards
> compatibility and imposes additional work on package authors and
> distros.

No one suggested any other solution to the filename problem.

Maybe we could get around this by adding a `cedet-compat' package that
loads everything everything in CEDET and provides all the old CEDET
feature names; then loading this file will provide everything a
third-party package needs to compile.

[Eli Zaretskii]

> From: Chong Yidong <cyd@...>
> Date: Mon, 28 Sep 2009 11:31:51 -0400
>
> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

I see warnings about shadowing libraries, after bootstrapping:

  This site has duplicate Lisp libraries with the same name.
  If a locally-installed Lisp library overrides a library in the Emacs release,
  that can cause trouble, and you should probably remove the locally-installed
  version unless you know what you are doing.

  emacs/lisp/format hides emacs/lisp/cedet/semantic/format
  emacs/lisp/emacs-lisp/debug hides emacs/lisp/cedet/semantic/debug
  emacs/lisp/complete hides emacs/lisp/cedet/semantic/complete
  emacs/lisp/emacs-lisp/chart hides emacs/lisp/cedet/semantic/chart
  emacs/lisp/loaddefs hides emacs/lisp/cedet/semantic/loaddefs
  emacs/lisp/sort hides emacs/lisp/cedet/semantic/sort
  emacs/lisp/cedet/semantic/wisent hides emacs/lisp/cedet/semantic/wisent/wisent
  emacs/lisp/progmodes/grep hides emacs/lisp/cedet/semantic/symref/grep
  emacs/lisp/emacs-lisp/debug hides emacs/lisp/cedet/semantic/bovine/debug
  emacs/lisp/emacs-lisp/debug hides emacs/lisp/cedet/semantic/analyze/debug
  emacs/lisp/complete hides emacs/lisp/cedet/semantic/analyze/complete

  11 Emacs Lisp load-path shadowings were found

[Phil Hagelberg-2]

Chong Yidong <cyd@...> writes:

> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.
>
> I have done what I can to clean up CEDET to conform to Emacs standards;
> if you see anything I missed, please go ahead and make the change.

Thanks. I am working on Rudel, a library that requires CEDET, and this
should make the install process much easier.

Rudel uses eieio as well as inversion.el, fame.el, and working.el. The
last three of these are files from CEDET's common/ directory. From what
I can tell, fame.el and working.el were not included in the merge. Was
this intentional? What were the deciding factors in what to include?

Perhaps they could be offered using package.el if we decide to integrate
it into Emacs?

-Phil

[seewhydee]

Eli Zaretskii <eliz@...> writes:

> I see warnings about shadowing libraries, after bootstrapping:
>
>   This site has duplicate Lisp libraries with the same name.
>   If a locally-installed Lisp library overrides a library in the Emacs release,
>   that can cause trouble, and you should probably remove the locally-installed
>   version unless you know what you are doing.

That's strange.  Does your load path include lisp/cedet/semantic after
bootstrapping, and if so is there a subdirs.el in lisp/cedet for some
reason?  It should not be there; I made a change in Makefile.in
specifically to prevent subdirs.el from being created in that directory.

[Ulrich Mueller-2]

>>>>> On Mon, 28 Sep 2009, Chong Yidong wrote:

>> Was this renaming of files really necessary? It breaks backwards
>> compatibility and imposes additional work on package authors and
>> distros.

> No one suggested any other solution to the filename problem.

The obvious solution is not to support CEDET on platforms with 8+3
filenames ...

> Maybe we could get around this by adding a `cedet-compat' package
> that loads everything everything in CEDET and provides all the old
> CEDET feature names; then loading this file will provide everything
> a third-party package needs to compile.

Not sure if loading everything at once is a good idea. CEDET is huge.
But couldn't at least the old feature names be provided by the single
files? (As it was done for newsticker-*, for example.)

Ulrich

[Eli Zaretskii]

> From: Chong Yidong <cyd@...>
> Cc: emacs-devel@...
> Date: Mon, 28 Sep 2009 14:25:48 -0400
>
> Eli Zaretskii <eliz@...> writes:
>
> > I see warnings about shadowing libraries, after bootstrapping:
> >
> >   This site has duplicate Lisp libraries with the same name.
> >   If a locally-installed Lisp library overrides a library in the Emacs release,
> >   that can cause trouble, and you should probably remove the locally-installed
> >   version unless you know what you are doing.
>
> That's strange.  Does your load path include lisp/cedet/semantic after
> bootstrapping

Yes, it includes cedet, cedet/semantic, cedet/semantic/wisent,
cedet/semantic/symref, cedet/semantic/decorate, cedet/semantic/bovine,
and cedet/semantic/analyze

> and if so is there a subdirs.el in lisp/cedet for some
> reason?

Yes, there is.  It says this:

    (normal-top-level-add-to-load-path '("semantic" ))

There's also subdirs.el in cedet/semantic.

> It should not be there; I made a change in Makefile.in
> specifically to prevent subdirs.el from being created in that directory.
 
What change you made, and in what Makefile.in?

All I can say is that I ran `confugure' and `make -j6 bootstrap'.  And
I have the Bash history to prove that.

[Time passes...]  Ah, I think I see the problem: this subdirs.el is
very old, from 2 weeks ago.  I think it was created when you added the
directories in the CEDET branch, at which time they appeared (as
empty) on HEAD as well, and then make-subdirs created the file.  If I
delete that file, the problem is gone.

So maybe "make bootstrap" should delete all subdirs.el, as cleanup.

[Andreas Schwab-2]

Eli Zaretskii <eliz@...> writes:

> [Time passes...]  Ah, I think I see the problem: this subdirs.el is
> very old, from 2 weeks ago.  I think it was created when you added the
> directories in the CEDET branch, at which time they appeared (as
> empty) on HEAD as well, and then make-subdirs created the file.

You should always pass -P to cvs update.

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[seewhydee]

Ulrich Mueller <ulm@...> writes:

>>>>>> On Mon, 28 Sep 2009, Chong Yidong wrote:
>
>>> Was this renaming of files really necessary? It breaks backwards
>>> compatibility and imposes additional work on package authors and
>>> distros.
>
>> No one suggested any other solution to the filename problem.
>
> The obvious solution is not to support CEDET on platforms with 8+3
> filenames ...

I'm no expert, but according to Eli, having files longer than 8+3 in the
tarball leads to problems unpacking the tarball on DOS, and other
problems on some versions of Windows:

http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg00149.html
http://lists.gnu.org/archive/html/emacs-devel/2005-12/msg01709.html

>> Maybe we could get around this by adding a `cedet-compat' package
>> that loads everything everything in CEDET and provides all the old
>> CEDET feature names; then loading this file will provide everything
>> a third-party package needs to compile.
>
> Not sure if loading everything at once is a good idea. CEDET is huge.
> But couldn't at least the old feature names be provided by the single
> files? (As it was done for newsticker-*, for example.)

We can do that, but how does this solve the problem?  The old `require'
calls still won't find the correct file (unless we implement feature
aliases or something like that).

[Andreas Schwab-2]

Chong Yidong <cyd@...> writes:

> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

Compiling /home/andreas/src/emacs/emacs/lisp/cedet/semantic.el

In toplevel form:
../../emacs/lisp/cedet/semantic.el:33:1:Error: Given parent class semantic-symref-tool-baseclass is not a class
make[3]: *** [compile-last] Error 1

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Ulrich Mueller-2]

>>>>> On Mon, 28 Sep 2009, Chong Yidong wrote:

>> The obvious solution is not to support CEDET on platforms with 8+3
>> filenames ...

> I'm no expert, but according to Eli, having files longer than 8+3
> in the tarball leads to problems unpacking the tarball on DOS, and
> other problems on some versions of Windows:

Supporting such antediluvian platforms is nice as long as it's
possible without too much effort. But if it becomes too much of a
burden one should reconsider if it's worthwhile (IMHO).

The renaming also increases the differences between Emacs and XEmacs
and packages intended for both will have to add further case
distinctions.

>> But couldn't at least the old feature names be provided by the
>> single files? (As it was done for newsticker-*, for example.)

> We can do that, but how does this solve the problem? The old
> `require' calls still won't find the correct file (unless we
> implement feature aliases or something like that).

It wouldn't solve it completely, but once the file is loaded the
feature (with the right name) will be present, and the third-party
package will run.

Ulrich

[Rupert Swarbrick-2]

Ulrich Mueller <ulm@...> writes:
>> I'm no expert, but according to Eli, having files longer than 8+3
>> in the tarball leads to problems unpacking the tarball on DOS, and
>> other problems on some versions of Windows:
>
> Supporting such antediluvian platforms is nice as long as it's
> possible without too much effort. But if it becomes too much of a
> burden one should reconsider if it's worthwhile (IMHO).

antediluvian. Windows. Well, maybe, but on which of the platforms on
which Emacs runs does it have the most users? Come the revolution, we
FOSSers can drop compatibility hacks but until then, comrades, I'm
afraid we'll have to keep making allowances for those still in chains.


Rupert

(Who didn't write that last sentence grinning. Of course not)

[Alan Mackenzie]

Hi, there!

On Mon, Sep 28, 2009 at 11:31:51AM -0400, Chong Yidong wrote:
> I have merged most of the CEDET branch into the trunk.  You may need to
> bootstrap; please let me know if there are any build failures.

Without the bootstrap, it failed to compile the cedet sources.  With a
make bootstrap, it just worked, out of the box.  :-)

> I have done what I can to clean up CEDET to conform to Emacs standards;
> if you see anything I missed, please go ahead and make the change.

> Currently, the interface to Semantic is via "M-x semantic-mode", and to
> EDE via "M-x global-ede-mode"; these should install a "Development" menu
> on the menu bar that can be used to enable further features.
> Suggestions about improving this interface, and the CEDET integration in
> general, are welcome.

> (If you want to make bigger changes to the internals of CEDET itself,
> please discuss first, because we need to coordinate that kind of change
> with upstream.)

Quick question.  Are there any CEDET manuals in this build?  I didn't
see any.

--
Alan Mackenzie (Nuremberg, Germany).

[Andreas Schwab-2]

> Compiling /home/andreas/src/emacs/emacs/lisp/cedet/semantic.el
>
> In toplevel form:
> ../../emacs/lisp/cedet/semantic.el:33:1:Error: Given parent class semantic-symref-tool-baseclass is not a class
> make[3]: *** [compile-last] Error 1

That was due to a broken loaddefs file.

Andreas.

--
Andreas Schwab, schwab@...
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[seewhydee]

Alan Mackenzie <acm@...> writes:

> Quick question.  Are there any CEDET manuals in this build?  I didn't
> see any.

They need to go in doc/misc, but I haven't done that yet.  (They
probably need to be checked too.)

I'll do this over the next few days, unless someone would like to do it
for me (they can be found in the CEDET upstream repository).

[seewhydee]

Phil Hagelberg <phil@...> writes:

> Rudel uses eieio as well as inversion.el, fame.el, and working.el. The
> last three of these are files from CEDET's common/ directory. From what
> I can tell, fame.el and working.el were not included in the merge. Was
> this intentional? What were the deciding factors in what to include?

I didn't include working.el (and fame.el, which is only there for
working.el) because I couldn't work out what advantage it brought over
the built-in progress reporter, which is a couple of hundred lines in
subr.el, already documented in the manual, and works fine.  This seems
too big a solution for a problem that's tangentially related to the rest
of CEDET, but maybe you can convince me otherwise.

As for the other omitted stuff, there are a couple of files in Semantic
not written by Eric that we don't have paperwork for yet (the Imenu
support and the Erlang and Python parsers).  Also the Srecode template
files and Semantic grammar files, which I haven't figured out where to
put (maybe a subdirectory in admin; any help with this task would be
appreciated).  And I may have overlooked some other things.

[Ulrich Mueller-2]

>>>>> On Mon, 28 Sep 2009, Rupert Swarbrick wrote:

>>> I'm no expert, but according to Eli, having files longer than 8+3
>>> in the tarball leads to problems unpacking the tarball on DOS, and
>>> other problems on some versions of Windows:
>>
>> Supporting such antediluvian platforms is nice as long as it's
>> possible without too much effort. But if it becomes too much of a
>> burden one should reconsider if it's worthwhile (IMHO).

> antediluvian. Windows.

;-)

> Well, maybe, but on which of the platforms on which Emacs runs does
> it have the most users? Come the revolution, we FOSSers can drop
> compatibility hacks but until then, comrades, I'm afraid we'll have
> to keep making allowances for those still in chains.

As far as I understand it, the 8+3 limitation is only relevant for
MS-DOS and very old (pre-NT?) MS-Windows versions. So users of recent
Windows should not be affected by it.

Ulrich

[Phil Hagelberg-2]

Chong Yidong <cyd@...> writes:

> This seems too big a solution for a problem that's tangentially
> related to the rest of CEDET, but maybe you can convince me otherwise.

Not at all, I'd rather remove the working.el dependency from
Rudel itself. Thanks for the explanation.

-Phil