CEDET merge

CEDET merge

[Chong Yidong]

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.)

Re: CEDET merge

[Ulrich Mueller]

>>>>> 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/

Re: CEDET merge

[Chong Yidong]

Ulrich Mueller <ulm@gentoo.org> 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.

Re: CEDET merge

[Ulrich Mueller]

>>>>> 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

Re: CEDET merge

[Chong Yidong]

Ulrich Mueller <ulm@gentoo.org> 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).

Re: CEDET merge

[Ulrich Mueller]

>>>>> 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

Re: CEDET merge

[Rupert Swarbrick]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]


Ulrich Mueller <ulm@gentoo.org> 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)

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: CEDET merge

[Ulrich Mueller]

>>>>> 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

Re: CEDET merge

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> 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.

Re: CEDET merge

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> 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

Re: CEDET merge

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> 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.

Re: CEDET merge

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 28 Sep 2009 14:25:48 -0400
> 
> Eli Zaretskii <eliz@gnu.org> 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.

Re: CEDET merge

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> 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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> 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

Re: CEDET merge

[Chong Yidong]

Phil Hagelberg <phil@hagelb.org> 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.

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> 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

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> 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.

The reason Rudel uses the CEDET one vs the built-in Emacs one is that it
needs a way to indicate that something is happening without knowing the
overall percentage of the task that is actually complete. I believe this
is commonly known as "pulsing" or a "spinner".

We could probably implement this as an addition to the built-in progress
reporter in subr.el; would this be a welcome feature?

-Phil

Re: CEDET merge

[Chong Yidong]

Phil Hagelberg <phil@hagelb.org> writes:

> The reason Rudel uses the CEDET one vs the built-in Emacs one is that it
> needs a way to indicate that something is happening without knowing the
> overall percentage of the task that is actually complete. I believe this
> is commonly known as "pulsing" or a "spinner".
>
> We could probably implement this as an addition to the built-in progress
> reporter in subr.el; would this be a welcome feature?

Yes, and it should be easy to implement too.

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> Phil Hagelberg <phil@hagelb.org> writes:
>> The reason Rudel uses the CEDET one vs the built-in Emacs one is that it
>> needs a way to indicate that something is happening without knowing the
>> overall percentage of the task that is actually complete. I believe this
>> is commonly known as "pulsing" or a "spinner".
>>
>> We could probably implement this as an addition to the built-in progress
>> reporter in subr.el; would this be a welcome feature?
>
> Yes, and it should be easy to implement too.

Here's what I've come up with:

(defvar progress-pulse-values ["-" "\\" "|" "/"]
  "A vector of characters to use for pulsing progress reporters.")

(defun make-pulsing-progress-reporter (&optional message)
  "Return a pulsing progress reporter that display MESSAGE.
MESSAGE can contain all formatting characters accepted by
`format'. If message is nil, the string \"Working ...\" is
displayed.

Example:
(let ((rep (make-pulsing-progress-reporter \"Connecting\")))
  (dotimes (n 3)
    (sleep-for 0.1)
    (progress-reporter-pulse rep \"Connecting [new]\"))
  (dotimes (n 3)
    (sleep-for 0.1)
    (progress-reporter-pulse rep \"Connecting [synching]\"))
  (dotimes (n 3)
    (sleep-for 0.1)
    (progress-reporter-pulse rep \"Connecting [idle]\"))
  (progress-reporter-pulse rep \"Connecting \")
  (progress-reporter-done rep))"
  (cons nil ; total value is not known
    (vector nil 0 'dummy (or message "Working ... "))))

(defun progress-reporter-pulse (reporter &optional new-message)
  "Advance pulsing indicator of REPORTER. Display NEW-MESSAGE if given."
  (let* ((parameters (cdr reporter))
         (message    (or new-message (aref parameters 3)))
         (index      (aref parameters 1))
         (new-index  (mod (+ index 1) 4)))
    (aset parameters 1 new-index)
    (aset parameters 3 message)
    (let ((message-log-max nil)) ; No logging
      (message "%s %s"
               (aref progress-pulse-values new-index)
               message))))

The example in the docstring should make it clear how this works. It's
fairly close to how the existing progress reporter works, but it's got
nil in a couple places in the data structure due to not knowing the
total progress.

I have my paperwork in. I could submit this as a patch if that's more
convenient, or you could find a place for it in subr.el.

Thanks!

-Phil

Re: CEDET merge

[Chong Yidong]

Phil Hagelberg <phil@hagelb.org> writes:

> (defun make-pulsing-progress-reporter (&optional message)

I think `make-progress-reporter' should do "pulsing" automatically if
min-value and max-value are null, instead of providing a new function.

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> writes:

> Phil Hagelberg <phil@hagelb.org> writes:
>
>> (defun make-pulsing-progress-reporter (&optional message)
>
> I think `make-progress-reporter' should do "pulsing" automatically if
> min-value and max-value are null, instead of providing a new function.

Good idea. I will implement that and send a patch.

-Phil

Re: CEDET merge

[Phil Hagelberg]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]

Phil Hagelberg <phil@hagelb.org> writes:

> Chong Yidong <cyd@stupidchicken.com> writes:
>> Phil Hagelberg <phil@hagelb.org> writes:
>>
>>> (defun make-pulsing-progress-reporter (&optional message)
>>
>> I think `make-progress-reporter' should do "pulsing" automatically if
>> min-value and max-value are null, instead of providing a new function.
>
> Good idea. I will implement that and send a patch.

The attached patch implements this. So make-progress-reporter will make
a pulsing reporter when min-value and max-value are not specified.

I made it so that you must use progress-reporter-pulse to update a
pulsing reporter, but I realized afterwards that it would be easy enough
to have progress-reporter-update check to see if the reporter is a
pulsing one or not and call the correct function underneath without the
caller having to think about it.

If you think this is a good idea I can make the change.

-Phil


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-pulsing-progress-reporter-functionality.patch --]
[-- Type: text/x-diff, Size: 3855 bytes --]

From 91f10af059ab03d50da990a332995b93aa4fcfbc Mon Sep 17 00:00:00 2001
From: Phil Hagelberg <technomancy@gmail.com>
Date: Wed, 30 Sep 2009 22:02:57 -0700
Subject: [PATCH] Add pulsing progress reporter functionality.

---
 lisp/subr.el |   41 ++++++++++++++++++++++++++++++-----------
 1 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index a7d3fcd..e26783f 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3415,9 +3415,8 @@ you call it."
   (when (>= value (car reporter))
     (progress-reporter-do-update reporter value)))
 
-(defun make-progress-reporter (message min-value max-value
-				       &optional current-value
-				       min-change min-time)
+(defun make-progress-reporter (message &optional min-value max-value
+				       current-value min-change min-time)
   "Return progress reporter object to be used with `progress-reporter-update'.
 
 MESSAGE is shown in the echo area.  When at least 1% of operation
@@ -3426,20 +3425,23 @@ MESSAGE.  When you call `progress-reporter-done', word \"done\"
 is printed after the MESSAGE.  You can change MESSAGE of an
 existing progress reporter with `progress-reporter-force-update'.
 
-MIN-VALUE and MAX-VALUE designate starting (0% complete) and
-final (100% complete) states of operation.  The latter should be
-larger; if this is not the case, then simply negate all values.
-Optional CURRENT-VALUE specifies the progress by the moment you
-call this function.  You should omit it or set it to nil in most
-cases since it defaults to MIN-VALUE.
+If provided, MIN-VALUE and MAX-VALUE designate starting (0%
+complete) and final (100% complete) states of operation.  The
+latter should be larger; if this is not the case, then simply
+negate all values.  Optional CURRENT-VALUE specifies the progress
+by the moment you call this function.  You should omit it or set
+it to nil in most cases since it defaults to MIN-VALUE.
 
 Optional MIN-CHANGE determines the minimal change in percents to
 report (default is 1%.)  Optional MIN-TIME specifies the minimal
 time before echo area updates (default is 0.2 seconds.)  If
 `float-time' function is not present, then time is not tracked
 at all.  If OS is not capable of measuring fractions of seconds,
-then this parameter is effectively rounded up."
+then this parameter is effectively rounded up.
 
+If MIN-VALUE and MAX-VALUE are unknown, they may be omitted to
+return a \"pulsing\" progress reporter. This should be updated
+using the `progress-reporter-pulse' function instead."
   (unless min-time
     (setq min-time 0.2))
   (let ((reporter
@@ -3447,7 +3449,7 @@ then this parameter is effectively rounded up."
 	       (vector (if (and (fboundp 'float-time)
 				(>= min-time 0.02))
 			   (float-time) nil)
-		       min-value
+		       (or min-value 0)
 		       max-value
 		       message
 		       (if min-change (max (min min-change 50) 1) 1)
@@ -3505,6 +3507,23 @@ change the displayed message."
 	  (message "%s%d%%" (aref parameters 3) percentage)
 	(message "%s" (aref parameters 3))))))
 
+(defvar progress-pulse-values ["-" "\\" "|" "/"]
+  "Characters to use for pulsing progress reporters.")
+
+(defun progress-reporter-pulse (reporter &optional new-message)
+  "Advance pulsing indicator of REPORTER. Display NEW-MESSAGE if given."
+  (let* ((parameters (cdr reporter))
+	 (message    (or new-message
+			 (aref parameters 3)))
+	 (index      (aref parameters 1))
+	 (new-index  (mod (+ index 1) 4)))
+    (aset parameters 1 new-index)
+    (aset parameters 3 message)
+    (let ((message-log-max nil)) ; No logging
+      (message "%s %s"
+	       (aref progress-pulse-values new-index)
+	       message))))
+
 (defun progress-reporter-done (reporter)
   "Print reporter's message followed by word \"done\" in echo area."
   (message "%sdone" (aref (cdr reporter) 3)))
-- 
1.6.0.4

Re: CEDET merge

[Stefan Monnier]

> I made it so that you must use progress-reporter-pulse to update a
> pulsing reporter, but I realized afterwards that it would be easy enough
> to have progress-reporter-update check to see if the reporter is a
> pulsing one or not and call the correct function underneath without the
> caller having to think about it.

> If you think this is a good idea I can make the change.

Yes, that would be even better, thank you,


        Stefan

Re: CEDET merge

[Phil Hagelberg]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I made it so that you must use progress-reporter-pulse to update a
>> pulsing reporter, but I realized afterwards that it would be easy enough
>> to have progress-reporter-update check to see if the reporter is a
>> pulsing one or not and call the correct function underneath without the
>> caller having to think about it.
>
>> If you think this is a good idea I can make the change.
>
> Yes, that would be even better, thank you,

I've attached the patches that implement this. Pulsing reporters can use
progress-reporter-update like normal ones and can have their messages
changed using progress-reporter-force-update.

thanks!
Phil


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-pulsing-progress-reporter-functionality.patch --]
[-- Type: text/x-diff, Size: 3855 bytes --]

From 91f10af059ab03d50da990a332995b93aa4fcfbc Mon Sep 17 00:00:00 2001
From: Phil Hagelberg <technomancy@gmail.com>
Date: Wed, 30 Sep 2009 22:02:57 -0700
Subject: [PATCH] Add pulsing progress reporter functionality.

---
 lisp/subr.el |   41 ++++++++++++++++++++++++++++++-----------
 1 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index a7d3fcd..e26783f 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3415,9 +3415,8 @@ you call it."
   (when (>= value (car reporter))
     (progress-reporter-do-update reporter value)))
 
-(defun make-progress-reporter (message min-value max-value
-				       &optional current-value
-				       min-change min-time)
+(defun make-progress-reporter (message &optional min-value max-value
+				       current-value min-change min-time)
   "Return progress reporter object to be used with `progress-reporter-update'.
 
 MESSAGE is shown in the echo area.  When at least 1% of operation
@@ -3426,20 +3425,23 @@ MESSAGE.  When you call `progress-reporter-done', word \"done\"
 is printed after the MESSAGE.  You can change MESSAGE of an
 existing progress reporter with `progress-reporter-force-update'.
 
-MIN-VALUE and MAX-VALUE designate starting (0% complete) and
-final (100% complete) states of operation.  The latter should be
-larger; if this is not the case, then simply negate all values.
-Optional CURRENT-VALUE specifies the progress by the moment you
-call this function.  You should omit it or set it to nil in most
-cases since it defaults to MIN-VALUE.
+If provided, MIN-VALUE and MAX-VALUE designate starting (0%
+complete) and final (100% complete) states of operation.  The
+latter should be larger; if this is not the case, then simply
+negate all values.  Optional CURRENT-VALUE specifies the progress
+by the moment you call this function.  You should omit it or set
+it to nil in most cases since it defaults to MIN-VALUE.
 
 Optional MIN-CHANGE determines the minimal change in percents to
 report (default is 1%.)  Optional MIN-TIME specifies the minimal
 time before echo area updates (default is 0.2 seconds.)  If
 `float-time' function is not present, then time is not tracked
 at all.  If OS is not capable of measuring fractions of seconds,
-then this parameter is effectively rounded up."
+then this parameter is effectively rounded up.
 
+If MIN-VALUE and MAX-VALUE are unknown, they may be omitted to
+return a \"pulsing\" progress reporter. This should be updated
+using the `progress-reporter-pulse' function instead."
   (unless min-time
     (setq min-time 0.2))
   (let ((reporter
@@ -3447,7 +3449,7 @@ then this parameter is effectively rounded up."
 	       (vector (if (and (fboundp 'float-time)
 				(>= min-time 0.02))
 			   (float-time) nil)
-		       min-value
+		       (or min-value 0)
 		       max-value
 		       message
 		       (if min-change (max (min min-change 50) 1) 1)
@@ -3505,6 +3507,23 @@ change the displayed message."
 	  (message "%s%d%%" (aref parameters 3) percentage)
 	(message "%s" (aref parameters 3))))))
 
+(defvar progress-pulse-values ["-" "\\" "|" "/"]
+  "Characters to use for pulsing progress reporters.")
+
+(defun progress-reporter-pulse (reporter &optional new-message)
+  "Advance pulsing indicator of REPORTER. Display NEW-MESSAGE if given."
+  (let* ((parameters (cdr reporter))
+	 (message    (or new-message
+			 (aref parameters 3)))
+	 (index      (aref parameters 1))
+	 (new-index  (mod (+ index 1) 4)))
+    (aset parameters 1 new-index)
+    (aset parameters 3 message)
+    (let ((message-log-max nil)) ; No logging
+      (message "%s %s"
+	       (aref progress-pulse-values new-index)
+	       message))))
+
 (defun progress-reporter-done (reporter)
   "Print reporter's message followed by word \"done\" in echo area."
   (message "%sdone" (aref (cdr reporter) 3)))
-- 
1.6.0.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Update-pulsing-reporters-to-work-with-regular-report.patch --]
[-- Type: text/x-diff, Size: 4320 bytes --]

From 89616487ab6f10fb5ec2d6369bddaf58745a40b3 Mon Sep 17 00:00:00 2001
From: Phil Hagelberg <technomancy@gmail.com>
Date: Fri, 2 Oct 2009 10:44:07 -0700
Subject: [PATCH] Update pulsing reporters to work with regular reporter functions.

Use progress-reporter-update for updating and
progress-reporter-force-update to update message. Remove
message-changing from progress-reporter-pulse.
---
 lisp/subr.el |   51 ++++++++++++++++++++++++++++-----------------------
 1 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/lisp/subr.el b/lisp/subr.el
index e26783f..bbf2051 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -3399,21 +3399,25 @@ The properties used on SYMBOL are `composefunc', `sendfunc',
 ;; digits of precision, it doesn't really matter here.  On the other
 ;; hand, it greatly simplifies the code.
 
-(defsubst progress-reporter-update (reporter value)
+(defsubst progress-reporter-update (reporter &optional value)
   "Report progress of an operation in the echo area.
+
+The first parameter, REPORTER, should be the result of a call to
+`make-progress-reporter'. For reporters for which the max value
+is known, the second argument determines the actual progress of
+operation; it must be between MIN-VALUE and MAX-VALUE as passed
+to `make-progress-reporter'.
+
 However, if the change since last echo area update is too small
 or not enough time has passed, then do nothing (see
 `make-progress-reporter' for details).
 
-First parameter, REPORTER, should be the result of a call to
-`make-progress-reporter'.  Second, VALUE, determines the actual
-progress of operation; it must be between MIN-VALUE and MAX-VALUE
-as passed to `make-progress-reporter'.
-
-This function is very inexpensive, you may not bother how often
-you call it."
-  (when (>= value (car reporter))
-    (progress-reporter-do-update reporter value)))
+In this case, this function is very inexpensive, you need not
+care how often you call it."
+  (if (progress-reporter-pulsing-p reporter)
+      (progress-reporter-pulse reporter)
+    (when (>= value (car reporter))
+      (progress-reporter-do-update reporter value))))
 
 (defun make-progress-reporter (message &optional min-value max-value
 				       current-value min-change min-time)
@@ -3440,8 +3444,7 @@ at all.  If OS is not capable of measuring fractions of seconds,
 then this parameter is effectively rounded up.
 
 If MIN-VALUE and MAX-VALUE are unknown, they may be omitted to
-return a \"pulsing\" progress reporter. This should be updated
-using the `progress-reporter-pulse' function instead."
+return a \"pulsing\" progress reporter."
   (unless min-time
     (setq min-time 0.2))
   (let ((reporter
@@ -3468,7 +3471,9 @@ change the displayed message."
       (aset parameters 3 new-message))
     (when (aref parameters 0)
       (aset parameters 0 (float-time)))
-    (progress-reporter-do-update reporter value)))
+    (if (progress-reporter-pulsing-p reporter)
+        (progress-reporter-pulse reporter)
+      (progress-reporter-do-update reporter value))))
 
 (defun progress-reporter-do-update (reporter value)
   (let* ((parameters   (cdr reporter))
@@ -3510,19 +3515,19 @@ change the displayed message."
 (defvar progress-pulse-values ["-" "\\" "|" "/"]
   "Characters to use for pulsing progress reporters.")
 
-(defun progress-reporter-pulse (reporter &optional new-message)
-  "Advance pulsing indicator of REPORTER. Display NEW-MESSAGE if given."
+(defun progress-reporter-pulsing-p (reporter)
+  "Return t if REPORTER has an unknown max value."
+  (null (aref (cdr reporter) 2)))
+
+(defun progress-reporter-pulse (reporter)
+  "Advance pulsing indicator of REPORTER."
   (let* ((parameters (cdr reporter))
-	 (message    (or new-message
-			 (aref parameters 3)))
-	 (index      (aref parameters 1))
-	 (new-index  (mod (+ index 1) 4)))
-    (aset parameters 1 new-index)
-    (aset parameters 3 message)
+	 (index      (+ (aref parameters 1) 1)))
+    (aset parameters 1 index)
     (let ((message-log-max nil)) ; No logging
       (message "%s %s"
-	       (aref progress-pulse-values new-index)
-	       message))))
+	       (aref progress-pulse-values (mod index 4))
+	       (aref parameters 3)))))
 
 (defun progress-reporter-done (reporter)
   "Print reporter's message followed by word \"done\" in echo area."
-- 
1.6.0.4

progress-reporter (was: CEDET merge)

[Michael Albinus]

Phil Hagelberg <phil@hagelb.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I made it so that you must use progress-reporter-pulse to update a
>>> pulsing reporter, but I realized afterwards that it would be easy enough
>>> to have progress-reporter-update check to see if the reporter is a
>>> pulsing one or not and call the correct function underneath without the
>>> caller having to think about it.
>>
>>> If you think this is a good idea I can make the change.
>>
>> Yes, that would be even better, thank you,
>
> I've attached the patches that implement this. Pulsing reporters can use
> progress-reporter-update like normal ones and can have their messages
> changed using progress-reporter-force-update.

I'm wondering whether this patch could be applied to the trunk. I'd
like to use it in Tramp, for huge copies, and alike.

> thanks!
> Phil

Best regards, Michael.

Re: CEDET merge

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> 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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: CEDET merge

[Andreas Schwab]

> 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@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: CEDET merge

[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).

Re: CEDET merge

[Chong Yidong]

Alan Mackenzie <acm@muc.de> 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).

Re: CEDET merge

[Glenn Morris]

Chong Yidong wrote:

> I have merged most of the CEDET branch into the trunk.

It seems you did not merge semantic/adebug.el, was this deliberate?

semantic/db-find.el claims that data-debug-insert-tag-list is defined
in data-debug.el, but it is not, it is defined in adebug.el, which is
not present in the trunk.

Re: CEDET merge

[Eric M. Ludlam]

On Tue, 2009-09-29 at 00:28 -0400, Glenn Morris wrote:
> Chong Yidong wrote:
> 
> > I have merged most of the CEDET branch into the trunk.
> 
> It seems you did not merge semantic/adebug.el, was this deliberate?
> 
> semantic/db-find.el claims that data-debug-insert-tag-list is defined
> in data-debug.el, but it is not, it is defined in adebug.el, which is
> not present in the trunk.
> 

Your email has reminded me that I've wanted to rename semantic-adebug.el
to something more descriptive.  It was originally a semantic specific
tool which I generalized as a data-debug.el for most things in Emacs.

Not that I have a fabulous name in mind though.  "a" was just a vowel to
go along with "e" debug which is a bit lame.  It should probably be
semantic-datadebug.el to match up with eieio-datadebug.el.  (Using the
parlance of the CEDET suite on sourceforge.  For Emacs I guess it would
be semantic/datadebug.el.)

Eric

Re: CEDET merge

[Juanma Barranquero]

On Mon, Sep 28, 2009 at 17:31, Chong Yidong <cyd@stupidchicken.com> 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.

semantic/cedet/wisent/javat-wy.el has coding issues, because of this line:

     ("char" summary "Integral primitive type ('^@' to '\357\227\227')
(0 to 65535)")

so on Windows it is decoded as "=(Unix)" (i.e., no-conversion, LF),
and does not compile:

In toplevel form:
javat-wy.el:680:36:Error: End of file during parsing

    Juanma

Re: CEDET merge

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 30 Sep 2009 11:32:25 +0200
> Cc: emacs-devel@gnu.org
> 
> semantic/cedet/wisent/javat-wy.el has coding issues, because of this line:
> 
>      ("char" summary "Integral primitive type ('^@' to '\357\227\227')
> (0 to 65535)")
> 
> so on Windows it is decoded as "=(Unix)" (i.e., no-conversion, LF),

The same happens on Unix, because the null byte forces the file to be
treated as binary.

> and does not compile:
> 
> In toplevel form:
> javat-wy.el:680:36:Error: End of file during parsing

Why, because the lines actually have CRLF Windows-style EOLs on your
machine?  Or for some other reason?  IOW, I don't see why
no-conversion should cause the file not to compile, and only on
Windows.  What am I missing?

Anyway, 2 ideas to work around this:

  . Replace the null byte with \000

  . Put "inhibit-null-byte-detection: t" in file-local variables.

Re: CEDET merge

[Juanma Barranquero]

On Wed, Sep 30, 2009 at 20:38, Eli Zaretskii <eliz@gnu.org> wrote:

>> and does not compile:
>>
>> In toplevel form:
>> javat-wy.el:680:36:Error: End of file during parsing
>
> Why, because the lines actually have CRLF Windows-style EOLs on your
> machine?

Checking it out with CVS, yes, it has CRLF EOLs. In fact, editing it
all lines end with ^M.

> IOW, I don't see why
> no-conversion should cause the file not to compile, and only on
> Windows.  What am I missing?

The CRs, apparently.

> Anyway, 2 ideas to work around this:
>
>  . Replace the null byte with \000

That works.

    Juanma

Re: CEDET merge

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> 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.

Thanks a lot I'm very curious about this new features.

Giving the ede part a quick try[0] I stumbled upon a bunch of problems:

- After enabling global-ede-mode mode first observation was, that the
  new Development-menu was not accessible when using the pseudo menu on
  an tty (haven't tested an graphical interface yet): <F10> shows
  `---Development' among the menu items, which cant be selected.

- After creating a new project of the type `automake' (ede-new) and
  adding a new target with one source file (plain hello world in c) I
  tried `ede-compile-target' which reviled an error in one provide form.
  This patch fixes it:

diff -r d4a1d308c9fe lisp/cedet/ede/srecode.el
--- a/lisp/cedet/ede/srecode.el	Wed Sep 30 11:07:53 2009 +0200
+++ b/lisp/cedet/ede/srecode.el	Wed Sep 30 12:08:48 2009 +0200
@@ -101,6 +101,6 @@
 
     ))
 
-(provide 'ede-srecode)
+(provide 'ede/srecode)
 
 ;;; ede-srecode.el ends here

- But after that fix compiling still fails.  Now with:
  eieio-generic-call-primary-only: Method srecode-template-get-table called on nil

Any ideas?

cheers
sascha

[0] Disclaimer: I have never used CEDET before, so if some of my reports
    don't make any sense, please tell me so...
-- 
Sascha Wilde
Life's too short to read boring signatures

Re: CEDET merge

[Sascha Wilde]

Sascha Wilde <wilde@sha-bang.de> wrote:
> -(provide 'ede-srecode)
> +(provide 'ede/srecode)

This was fixed in current CVS, thanks.

> - But after that fix compiling still fails.  Now with:
>   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil

This problem is still there.  A question to all CEDET/EDE experts: is
this an bug or am I missing something?

(and FWIW the development menu is still broken in tty mode, on X11/gtk
it works well).
-- 
Sascha Wilde
Nothing is fool-proof to a sufficiently talented fool.

Re: CEDET merge

[Eric M. Ludlam]

On Thu, 2009-10-01 at 12:58 +0200, Sascha Wilde wrote:
> Sascha Wilde <wilde@sha-bang.de> wrote:
> > -(provide 'ede-srecode)
> > +(provide 'ede/srecode)
> 
> This was fixed in current CVS, thanks.
> 
> > - But after that fix compiling still fails.  Now with:
> >   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil
> 
> This problem is still there.  A question to all CEDET/EDE experts: is
> this an bug or am I missing something?

Chong Yidong said he hadn't figured out where to put the SRecode
templates.  Since EDE uses Srecode to templates to create Makefiles,
that is likely the problem.  The way SRecode looks up template files may
also not be compatible with where the templates will eventually live in
Emacs, so that would need to be updated.

Short term, you could get the templates from CEDET CVS in
cedet/srecode/templates and cedet/ede/templates and place them in
equivalent locations just under srecode.el and ede.el to get past this
until there is a home for SRecode Templates in Emacs.

Eric

Re: CEDET merge

[Sascha Wilde]

"Eric M. Ludlam" <eric@siege-engine.com> wrote:
> On Thu, 2009-10-01 at 12:58 +0200, Sascha Wilde wrote:
>> Sascha Wilde <wilde@sha-bang.de> wrote:
>> > - But after that fix compiling still fails.  Now with:
>> >   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil
>> This problem is still there.  A question to all CEDET/EDE experts: is
>> this an bug or am I missing something?
>
> Chong Yidong said he hadn't figured out where to put the SRecode
> templates.  Since EDE uses Srecode to templates to create Makefiles,
> that is likely the problem.

Thanks for your explanation.

> Short term, you could get the templates from CEDET CVS in
> cedet/srecode/templates and cedet/ede/templates and place them in
> equivalent locations just under srecode.el and ede.el to get past this
> until there is a home for SRecode Templates in Emacs.

I'll give it a try...

cheers
sascha
-- 
>++++++[<+++++++++++>-]<+.>+++[<++++++>-]<.---.---------.++++++.++++.---------
-.+++++++++++.+++++.>+++++++[<-------->-]<-.>++++++[<+++++++>-]<+.--.+++..----
---.-.>++++++[<------>-]<.>++++[<+++++++++++++>-]<.------------.---.>++++++[<-
----->-]<-.>+++++[<+++++++>-]<.--.>+++[<++++++>-]<+.>++++++++[<--------->-]<--.

Re: CEDET merge

[Sascha Wilde]

Sascha Wilde <wilde@sha-bang.de> wrote:
> "Eric M. Ludlam" <eric@siege-engine.com> wrote:
>> On Thu, 2009-10-01 at 12:58 +0200, Sascha Wilde wrote:
>>> Sascha Wilde <wilde@sha-bang.de> wrote:
>>> > - But after that fix compiling still fails.  Now with:
>>> >   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil
[...]
>> Short term, you could get the templates from CEDET CVS in
>> cedet/srecode/templates and cedet/ede/templates and place them in
>> equivalent locations just under srecode.el and ede.el to get past this
>> until there is a home for SRecode Templates in Emacs.
>
> I'll give it a try...

hmm, didn't work -- or maybe I haven't fully understood what to do.
Here is what I tried:
- I checked out the current cedet head from CVS
- I copied the directory cedet/ede/templates to
  /usr/share/emacs/23.1.50/lisp/cedet/ede/templates and
  cedet/srecode/templates to
  /usr/share/emacs/23.1.50/lisp/cedet/srecode/templates

That didn't work, so I tried puting all *.srt files from
cedet/ede/templates directly under
/usr/share/emacs/23.1.50/lisp/cedet/ede/ (and same for
/usr/share/emacs/23.1.50/lisp/cedet/srecode/) but this didn't work
either....

What am I missing?

sascha
-- 
Sascha Wilde

Programmer - A red-eyed, mumbling mammal capable of conversing with
             inanimate objects.

Re: CEDET merge

[Eric M. Ludlam]

On Thu, 2009-10-01 at 18:28 +0200, Sascha Wilde wrote:
> Sascha Wilde <wilde@sha-bang.de> wrote:
> > "Eric M. Ludlam" <eric@siege-engine.com> wrote:
> >> On Thu, 2009-10-01 at 12:58 +0200, Sascha Wilde wrote:
> >>> Sascha Wilde <wilde@sha-bang.de> wrote:
> >>> > - But after that fix compiling still fails.  Now with:
> >>> >   eieio-generic-call-primary-only: Method srecode-template-get-table called on nil
> [...]
> >> Short term, you could get the templates from CEDET CVS in
> >> cedet/srecode/templates and cedet/ede/templates and place them in
> >> equivalent locations just under srecode.el and ede.el to get past this
> >> until there is a home for SRecode Templates in Emacs.
> >
> > I'll give it a try...
> 
> hmm, didn't work -- or maybe I haven't fully understood what to do.
> Here is what I tried:
> - I checked out the current cedet head from CVS
> - I copied the directory cedet/ede/templates to
>   /usr/share/emacs/23.1.50/lisp/cedet/ede/templates and
>   cedet/srecode/templates to
>   /usr/share/emacs/23.1.50/lisp/cedet/srecode/templates
> 
> That didn't work, so I tried puting all *.srt files from
> cedet/ede/templates directly under
> /usr/share/emacs/23.1.50/lisp/cedet/ede/ (and same for
> /usr/share/emacs/23.1.50/lisp/cedet/srecode/) but this didn't work
> either....
> 

I must apologize for not actually trying out the Emacs integration.  It
is pumpkin throwing season which keeps me busy.  (see
www.punkinchunkin.com for the sport, or www.siege-engine.com for my
team.)

Anyway, the template directory is set up like this for EDE:

  (let* ((lib (locate-library "ede.el" t))
	 (ededir (file-name-directory lib))
	 (tmpdir (file-name-as-directory
		  (expand-file-name "templates" ededir))))
    (when (not tmpdir)
      (error "Unable to location EDE Templates directory"))

    (require 'srecode-map)
    (add-to-list 'srecode-map-load-path tmpdir)
    (srecode-map-update-map t)


but you could just do this in your basic setup by specifying a load path
for srecode directly, as in the code above reveals.

Eric

Re: CEDET merge

[Sascha Wilde]

[-- Attachment #1: Type: text/plain, Size: 1799 bytes --]

"Eric M. Ludlam" <eric@siege-engine.com> wrote:
[...]
> I must apologize for not actually trying out the Emacs integration.  It
> is pumpkin throwing season which keeps me busy.  (see
> www.punkinchunkin.com for the sport, or www.siege-engine.com for my
> team.)

Thanks for your reply.  I have to admit, that I hardly read any more
convincing (and judging from the pictures: more impressive) excuse for
being less responsive than that...  ;-)

> Anyway, the template directory is set up like this for EDE:
>
>   (let* ((lib (locate-library "ede.el" t))
> 	 (ededir (file-name-directory lib))
> 	 (tmpdir (file-name-as-directory
> 		  (expand-file-name "templates" ededir))))
>     (when (not tmpdir)
>       (error "Unable to location EDE Templates directory"))
>
>     (require 'srecode-map)

FWIW: 'srecode/map with the Emacs integration.

>     (add-to-list 'srecode-map-load-path tmpdir)
>     (srecode-map-update-map t)

This (and some digging in the content of srecode-map-load-path) brought
me a step further.  I copied all ede and srecode templates from the
cedet CVS to ~/.srecode/ which was in my srecode-map-load-path.

Now I get an different error on any attempt to rebuild a projects
makefile (which afaiu is also a part of compiling).  From *Messages*:

Replace EDE Makefile
Compiling template default.srt...
0 templates compiled for nil
srecode-compile-templates: You must specify a MODE for your templates

Is more information needed than that provided during ede-new and
ede-new-target?

cheers
sascha
-- 
Sascha Wilde
"Structure is _nothing_ if it is all you got.  Skeletons _spook_ people if
 thwy try to walk around on their own.  I really wonder why XML does
 not."            -- Erik Naggum <erik@naggum.net> in comp.lang.lisp

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: CEDET merge

[Sascha Wilde]

[-- Attachment #1: Type: text/plain, Size: 808 bytes --]

Sascha Wilde <wilde@sha-bang.de> wrote:
> Now I get an different error on any attempt to rebuild a projects
> makefile (which afaiu is also a part of compiling).  From *Messages*:
>
> Replace EDE Makefile
> Compiling template default.srt...
> 0 templates compiled for nil
> srecode-compile-templates: You must specify a MODE for your templates

With the latest changes to the CEDET integration this problem vanished,
too.  Now Makefile generation by EDE basically works.

However I still witness a bunch problems with my simple test cases.

Is it useful to report them here or should I wait for the CEDET
integration process to become more complete?

cheers
sascha
-- 
Sascha Wilde : "Ist es nicht schon schlimm genug, dass ICH hier rumtrolle?"
             : (Henning Leise in d.o.c.)

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: CEDET merge

[Chong Yidong]

Sascha Wilde <wilde@sha-bang.de> writes:

> With the latest changes to the CEDET integration this problem vanished,
> too.  Now Makefile generation by EDE basically works.
>
> However I still witness a bunch problems with my simple test cases.
>
> Is it useful to report them here or should I wait for the CEDET
> integration process to become more complete?

Please, report them here.

Problems with EDE (was: CEDET merge)

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
>> However I still witness a bunch problems with my simple test cases.
[...]
> Please, report them here.

Summary: 
Problems with EDE automake projects:
- necessary compiler detection is missing from generated configure.ac
- AUTHORS, NEWS, README, Changelog are regenerated on every build

Details for reproduction:
-  emacs -Q
-  M-x global-ede-mode RET
-  M-x semantic-mode RET
-  M-x make-directory RET /tmp/cedet-test1 RET
-  C-x C-f /tmp/cedet-test1/test.c RET
- [In the buffer:]
   #include <stdio.h>
   int main () { puts("Hello EDE!"); }
-  C-x C-s
-  M-x ede-new RET
  Project Type: Automake
  Name: edetest
-  C-c . t
  Name: hello
  Type: program
  Add test.c to hello? (y or n) y
-  C-c . c
  I had to create the AUTHORS file for you.  Ok? (y or n) y
  [Same question for NEWS, README, Changelog, all answerde `y']

Now I get compilation output:

  -*- mode: compilation; default-directory: "/tmp/cedet-test1/" -*-
  Compilation started at Wed Oct  7 11:19:19

  aclocal;automake --add-missing;autoreconf;./configure;
  configure.ac:4: installing `./install-sh'
  configure.ac:4: installing `./missing'
  Makefile.am: installing `./INSTALL'
  Makefile.am: installing `./COPYING' using GNU General Public License v3 file
  Makefile.am:     Consider adding the COPYING file to the version control system
  Makefile.am:     for your code, to avoid questions about which license your project uses.
  configure.ac:5: required file `config.h.in' not found
  Makefile.am: installing `./depcomp'
  /usr/share/automake-1.11/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
  /usr/share/automake-1.11/am/depend2.am:   The usual way to define `am__fastdepCC' is to add `AC_PROG_CC'
  /usr/share/automake-1.11/am/depend2.am:   to `configure.ac' and run `aclocal' and `autoconf' again.
  /usr/share/automake-1.11/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
  /usr/share/automake-1.11/am/depend2.am:   The usual way to define `AMDEP' is to add one of the compiler tests
  /usr/share/automake-1.11/am/depend2.am:     AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC,
  /usr/share/automake-1.11/am/depend2.am:     AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC
  /usr/share/automake-1.11/am/depend2.am:   to `configure.ac' and run `aclocal' and `autoconf' again.
  Makefile.am: C source seen but `CC' is undefined
  Makefile.am:   The usual way to define `CC' is to add `AC_PROG_CC'
  Makefile.am:   to `configure.ac' and run `autoconf' again.
  /usr/share/automake-1.11/am/depend2.am: am__fastdepCC does not appear in AM_CONDITIONAL
  /usr/share/automake-1.11/am/depend2.am:   The usual way to define `am__fastdepCC' is to add `AC_PROG_CC'
  /usr/share/automake-1.11/am/depend2.am:   to `configure.ac' and run `aclocal' and `autoconf' again.
  /usr/share/automake-1.11/am/depend2.am: AMDEP does not appear in AM_CONDITIONAL
  /usr/share/automake-1.11/am/depend2.am:   The usual way to define `AMDEP' is to add one of the compiler tests
  /usr/share/automake-1.11/am/depend2.am:     AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC,
  /usr/share/automake-1.11/am/depend2.am:     AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC
  /usr/share/automake-1.11/am/depend2.am:   to `configure.ac' and run `aclocal' and `autoconf' again.
  Makefile.am: C source seen but `CC' is undefined
  Makefile.am:   The usual way to define `CC' is to add `AC_PROG_CC'
  Makefile.am:   to `configure.ac' and run `autoconf' again.
  autoreconf: automake failed with exit status: 1
  checking for a BSD-compatible install... /usr/bin/install -c
  checking whether build environment is sane... yes
  checking for a thread-safe mkdir -p... /bin/mkdir -p
  checking for gawk... gawk
  checking whether make sets $(MAKE)... yes
  configure: creating ./config.status
  config.status: error: cannot find input file: `Makefile.in'

  Compilation exited abnormally with code 1 at Wed Oct  7 11:19:30

As the error messages show: there is AC_PROG_CC or any equivalent
missing from the generated configure.ac.  After adding it manually:

- C-x b test.c RET
- C-c . c

Asks again for all files AUTHORS, NEWS, README and Changelog if they
should be created despite the fact that they are already there.  Even
more: it readds and thereby duplicates the automatic generated entries
(for AUTHORS and NEWS).

Answering no to any of there "create foo" questions immediately
terminates the whole ede build process, which IMO is a bug, too.

The actually build runs now successfully.
-- 
Sascha Wilde
    "Liebet eure Feinde, vielleicht schadet das ihrem Ruf" 
    (Stanislaw Jerzy Lec)

Re: Problems with EDE

[Sascha Wilde]

Summary: 
Problems with EDE make projects:
- Target are not created correctly in Makefile:

Details for reproduction:
-  emacs -Q
-  M-x global-ede-mode RET
-  M-x semantic-mode RET
-  M-x make-directory RET /tmp/cedet-test2 RET
-  C-x C-f /tmp/cedet-test2/test.c RET
- [In the buffer:]
   #include <stdio.h>
   int main () { puts("Hello EDE!"); }
-  C-x C-s
-  M-x ede-new RET
  Project Type: Make
  Name: edetest2
-  C-c . t
  Name: hello
  Type: program
  Add test.c to hello? (y or n) y
-  C-c . c

Now I get compilation output:

  -*- mode: compilation; default-directory: "/tmp/cedet-test2/" -*-
  Compilation started at Wed Oct  7 11:47:00

  make -f Makefile hello
  make: *** No rule to make target `hello'.  Stop.

  Compilation exited abnormally with code 2 at Wed Oct  7 11:47:00

A short look in the generated Makefile shows that there is no explicit
target `hello' defined (although a target `all' is there and references
`hello').

cheers
sascha
-- 
Sascha Wilde

Lisp is the red pill.
  -- John Fraser, comp.lang.lisp

Re: Problems with EDE

[Eric M. Ludlam]

I tried your sample w/ the non-integrated CEDET w/ a slightly older
Emacs 23, and the created Makefile was complete.  I have tests similar
to this with Make and Automake that all run to completion also.

As such, I'd guess something didn't translate properly in the merge.  I
can look into this, but it won't be soon.

Eric 

On Wed, 2009-10-07 at 11:49 +0200, Sascha Wilde wrote:
> Summary: 
> Problems with EDE make projects:
> - Target are not created correctly in Makefile:
> 
> Details for reproduction:
> -  emacs -Q
> -  M-x global-ede-mode RET
> -  M-x semantic-mode RET
> -  M-x make-directory RET /tmp/cedet-test2 RET
> -  C-x C-f /tmp/cedet-test2/test.c RET
> - [In the buffer:]
>    #include <stdio.h>
>    int main () { puts("Hello EDE!"); }
> -  C-x C-s
> -  M-x ede-new RET
>   Project Type: Make
>   Name: edetest2
> -  C-c . t
>   Name: hello
>   Type: program
>   Add test.c to hello? (y or n) y
> -  C-c . c
> 
> Now I get compilation output:
> 
>   -*- mode: compilation; default-directory: "/tmp/cedet-test2/" -*-
>   Compilation started at Wed Oct  7 11:47:00
> 
>   make -f Makefile hello
>   make: *** No rule to make target `hello'.  Stop.
> 
>   Compilation exited abnormally with code 2 at Wed Oct  7 11:47:00
> 
> A short look in the generated Makefile shows that there is no explicit
> target `hello' defined (although a target `all' is there and references
> `hello').
> 
> cheers
> sascha

Re: Problems with EDE

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> I tried your sample w/ the non-integrated CEDET w/ a slightly older
> Emacs 23, and the created Makefile was complete.  I have tests similar
> to this with Make and Automake that all run to completion also.
>
> As such, I'd guess something didn't translate properly in the merge.  I
> can look into this, but it won't be soon.

Sorry, this was my mistake.  While removing the use of ede-or in
source.el, I wrote the replacement form incorrectly.  I've checked in a
fix.

The target is now printed correctly, but there is a different
compilation error; I'll investigate further.

Re: Problems with EDE

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> The target is now printed correctly, but there is a different
> compilation error; I'll investigate further.

It seems the error occurs in upstream CEDET as well.  Following Sascha's
"Make" project recipe, I get

  make -f /home/cyd/tmp/Makefile all
  gcc     -c hello.c
  ld  -L. -o hello hello.o
  ld: warning: cannot find entry symbol _start; defaulting to 0000000008048074
  hello.o: In function `main':
  hello.c:(.text+0x19): undefined reference to `puts'
  make: *** [hello] Error 1

Why is EDE using ld rather than gcc to perform linking?

Re: Problems with EDE

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
>> The target is now printed correctly, 

Thanks a lot for working on this.  I can confirm, that compiling an
Automake Project now works.

But the problem with repeated creation of the documentation files
(AUTHRS, NEWS etc.) still persist.

And:

> It seems the error occurs in upstream CEDET as well.  Following Sascha's
> "Make" project recipe, I get
>
>   make -f /home/cyd/tmp/Makefile all
>   gcc     -c hello.c
>   ld  -L. -o hello hello.o
>   ld: warning: cannot find entry symbol _start; defaulting to 0000000008048074
>   hello.o: In function `main':
>   hello.c:(.text+0x19): undefined reference to `puts'
>   make: *** [hello] Error 1

I see this, too.

cheers
sascha
-- 
Sascha Wilde : "GUIs normally make it simple to accomplish simple 
             : actions and impossible to accomplish complex actions."
             : (Doug Gwyn - 22/Jun/91 in comp.unix.wizards)

Re: Problems with EDE

[Sascha Wilde]

Sascha Wilde <wilde@sha-bang.de> wrote:

> But the problem with repeated creation of the documentation files
> (AUTHRS, NEWS etc.) still persist.

Additional observation: this problem disappears when re-visiting an
Automake EDE project, where these files already exist, with an fresh
started emacs.

So I'd guess it's related to some kind of caching.

sascha
-- 
Sascha Wilde : "Der Nicht-Denkende glaubt, dass niemand denkt,
             : der Denkende weiss es!"
             : (Gabriel Laub)

Re: Problems with EDE

[Eric M. Ludlam]

On Wed, 2009-10-07 at 22:17 -0400, Chong Yidong wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
> 
> > The target is now printed correctly, but there is a different
> > compilation error; I'll investigate further.
> 
> It seems the error occurs in upstream CEDET as well.  Following Sascha's
> "Make" project recipe, I get
> 
>   make -f /home/cyd/tmp/Makefile all
>   gcc     -c hello.c
>   ld  -L. -o hello hello.o
>   ld: warning: cannot find entry symbol _start; defaulting to 0000000008048074
>   hello.o: In function `main':
>   hello.c:(.text+0x19): undefined reference to `puts'
>   make: *** [hello] Error 1
> 
> Why is EDE using ld rather than gcc to perform linking?

I wrote it in 1999, and at the time, that is what worked for me.

EDE actually will use a range of different linkers, and the ld one was
the first match.  If you use:

M-x customize-target RET

you can select a new linker, such as a g++ linker, or the gfortran
linker.  Looking in ede-proj-obj.el (ede/proj/obj.el ?) it is hopefully
obvious how to add new linkers here.  I think my test suite I use uses c
++ instead, and thus gets a different linker.  I apparently need to add
a new test. ;)

Eric

Re: Problems with EDE

[Miles Bader]

"Eric M. Ludlam" <eric@siege-engine.com> writes:
>> Why is EDE using ld rather than gcc to perform linking?
>
> I wrote it in 1999, and at the time, that is what worked for me.
>
> EDE actually will use a range of different linkers, and the ld one was
> the first match.

$(CC) is probably the best choice if you don't have any more detailed information.

-Miles

-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: Problems with EDE

[Sascha Wilde]

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

"Eric M. Ludlam" <eric@siege-engine.com> wrote:
> Looking in ede-proj-obj.el (ede/proj/obj.el ?) it is hopefully
> obvious how to add new linkers here.  I think my test suite I use uses c
> ++ instead, and thus gets a different linker.  I apparently need to add
> a new test. ;)

Hi *,

how about the following patch?  It fixes the problems for me.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 811 bytes --]

diff -r 1667bfa67b40 lisp/cedet/ede/proj-obj.el
--- a/lisp/cedet/ede/proj-obj.el	Thu Oct 08 11:07:26 2009 +0200
+++ b/lisp/cedet/ede/proj-obj.el	Thu Oct 08 15:20:44 2009 +0200
@@ -47,6 +47,7 @@
 				  ))
    (availablelinkers :initform (ede-g++-linker
 				;; Add more linker thingies here.
+				ede-gcc-linker
 				ede-ld-linker
 				ede-gfortran-linker
 				))
@@ -231,6 +232,18 @@
    :objectextention "")
   "Linker needed for c++ programs.")
 
+(defvar ede-gcc-linker
+  (ede-linker
+   "ede-gcc-linker"
+   :name "gcc"
+   :variables  '(("LD" . "gcc")
+		 ("LD_LINK" .
+		  "$(LD) $(LDFLAGS) -L. -o $@")
+		 )
+   :commands '("$(LD_LINK) $^")
+   :objectextention "")
+  "Generic gcc linker.")
+
 ;;; The EDE object compiler
 ;;
 (defmethod ede-proj-makefile-insert-variables ((this ede-object-compiler))

[-- Attachment #3: Type: text/plain, Size: 187 bytes --]


cheers
sascha
-- 
Sascha Wilde
    "Computers are good at following instructions,
     but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

Re: Problems with EDE

[Chong Yidong]

Sascha Wilde <wilde@sha-bang.de> writes:

> how about the following patch?  It fixes the problems for me.

Great minds think alike, I see.

Re: Problems with EDE

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> how about the following patch?  It fixes the problems for me.
>
> Great minds think alike, I see.

:-)

Anyway, please note David's comment.  I agree with him, that your code
should be renamed to ede-cc-linker (or otherwise be more specific, like
mine).

cheers
sascha
-- 
Sascha Wilde
Nothing is fool-proof to a sufficiently talented fool.

Re: Problems with EDE

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> I wrote it in 1999, and at the time, that is what worked for me.
>
> EDE actually will use a range of different linkers, and the ld one was
> the first match.  If you use:
>
> M-x customize-target RET
>
> you can select a new linker, such as a g++ linker, or the gfortran
> linker.  Looking in ede-proj-obj.el (ede/proj/obj.el ?) it is hopefully
> obvious how to add new linkers here.  I think my test suite I use uses c
> ++ instead, and thus gets a different linker.  I apparently need to add
> a new test. ;)

I see.  I added a new ede-gcc-linker, and the Make project now compiles
properly.  Here's a patch for your source tree:

*** cedet/ede/ede-proj-obj.el.~1.15.~	2009-08-18 19:56:57.000000000 -0400
--- cedet/ede/ede-proj-obj.el	2009-10-08 10:10:29.000000000 -0400
***************
*** 48,58 ****
  				  ;; fortran or pascal can be added here
  				  ))
     (availablelinkers :initform (ede-g++-linker
! 				;; Add more linker thingies here.
! 				ede-ld-linker
  				ede-gfortran-linker
  				))
!    (sourcetype :initform (ede-source-c 
  			  ede-source-c++
  			  ede-source-f77
  			  ede-source-f90
--- 48,59 ----
  				  ;; fortran or pascal can be added here
  				  ))
     (availablelinkers :initform (ede-g++-linker
! 				ede-gcc-linker
  				ede-gfortran-linker
+ 				ede-ld-linker
+ 				;; Add more linker thingies here.
  				))
!    (sourcetype :initform (ede-source-c
  			  ede-source-c++
  			  ede-source-f77
  			  ede-source-f90
***************
*** 109,114 ****
--- 110,125 ----
     :uselinker t)
    "Compiler for C sourcecode.")
  
+ (defvar ede-gcc-linker
+   (ede-linker
+    "ede-gcc-linker"
+    :name "gcc"
+    :sourcetype '(ede-source-c)
+    :variables  '(("C_LINK" . "$(CC) $(CFLAGS) $(LDFLAGS) -L."))
+    :commands '("$(C_LINK) -o $@ $^")
+    :objectextention "")
+   "Linker for C sourcecode.")
+ 
  (defvar ede-source-c++
    (ede-sourcecode "ede-source-c++"
  		  :name "C++"

Re: Problems with EDE

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> + (defvar ede-gcc-linker
> +   (ede-linker
> +    "ede-gcc-linker"
> +    :name "gcc"
> +    :sourcetype '(ede-source-c)
> +    :variables  '(("C_LINK" . "$(CC) $(CFLAGS) $(LDFLAGS) -L."))
> +    :commands '("$(C_LINK) -o $@ $^")
> +    :objectextention "")
> +   "Linker for C sourcecode.")

That's a cc-linker, not a gcc-linker.

-- 
David Kastrup

Re: Problems with EDE

[Eric M. Ludlam]

Thanks,

I finally applied this to my repository as well (plus modifications also
mentioned on this thread.)

Eric

On Thu, 2009-10-08 at 10:11 -0400, Chong Yidong wrote:
> "Eric M. Ludlam" <eric@siege-engine.com> writes:
> 
> > I wrote it in 1999, and at the time, that is what worked for me.
> >
> > EDE actually will use a range of different linkers, and the ld one was
> > the first match.  If you use:
> >
> > M-x customize-target RET
> >
> > you can select a new linker, such as a g++ linker, or the gfortran
> > linker.  Looking in ede-proj-obj.el (ede/proj/obj.el ?) it is hopefully
> > obvious how to add new linkers here.  I think my test suite I use uses c
> > ++ instead, and thus gets a different linker.  I apparently need to add
> > a new test. ;)
> 
> I see.  I added a new ede-gcc-linker, and the Make project now compiles
> properly.  Here's a patch for your source tree:
> 
> *** cedet/ede/ede-proj-obj.el.~1.15.~	2009-08-18 19:56:57.000000000 -0400
> --- cedet/ede/ede-proj-obj.el	2009-10-08 10:10:29.000000000 -0400
> ***************
> *** 48,58 ****
>   				  ;; fortran or pascal can be added here
>   				  ))
>      (availablelinkers :initform (ede-g++-linker
> ! 				;; Add more linker thingies here.
> ! 				ede-ld-linker
>   				ede-gfortran-linker
>   				))
> !    (sourcetype :initform (ede-source-c 
>   			  ede-source-c++
>   			  ede-source-f77
>   			  ede-source-f90
> --- 48,59 ----
>   				  ;; fortran or pascal can be added here
>   				  ))
>      (availablelinkers :initform (ede-g++-linker
> ! 				ede-gcc-linker
>   				ede-gfortran-linker
> + 				ede-ld-linker
> + 				;; Add more linker thingies here.
>   				))
> !    (sourcetype :initform (ede-source-c
>   			  ede-source-c++
>   			  ede-source-f77
>   			  ede-source-f90
> ***************
> *** 109,114 ****
> --- 110,125 ----
>      :uselinker t)
>     "Compiler for C sourcecode.")
>   
> + (defvar ede-gcc-linker
> +   (ede-linker
> +    "ede-gcc-linker"
> +    :name "gcc"
> +    :sourcetype '(ede-source-c)
> +    :variables  '(("C_LINK" . "$(CC) $(CFLAGS) $(LDFLAGS) -L."))
> +    :commands '("$(C_LINK) -o $@ $^")
> +    :objectextention "")
> +   "Linker for C sourcecode.")
> + 
>   (defvar ede-source-c++
>     (ede-sourcecode "ede-source-c++"
>   		  :name "C++"

defalias customize-* in ede.el (was: Problems with EDE)

[Reiner Steib]

On Thu, Oct 08 2009, Eric M. Ludlam wrote:

> EDE actually will use a range of different linkers, and the ld one was
> the first match.  If you use:
>
> M-x customize-target RET

Are these alias a good idea?  The names seem to generic to me.

,----[ lisp/cedet/ede.el ]
| (defalias 'customize-project 'ede-customize-project)
| [...]
| (defalias 'customize-target 'ede-customize-current-target)
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Problems with EDE

[Sascha Wilde]

Yet another one:
ede-make-dist does not work for ede automake projects:

  -*- mode: compilation; default-directory: "/tmp/cedet-test1/" -*-
  Compilation started at Thu Oct  8 22:52:13

  make -f /tmp/cedet-test1/Makefile.am dist
  make: *** No rule to make target `dist'.  Stop.

  Compilation exited abnormally with code 2 at Thu Oct  8 22:52:13

Using the Makefile.am is obviously wrong.  The actual Makefile contains
an working dist target.  

For ede make projects ede-make-dist works.

cheers
sascha
-- 
Sascha Wilde
... mein Opa [...]  würde an dieser Stelle zu Dir sagen: Junge, such Dir 
ne Frau, bau Dir ein Haus, mach ein Kind und laß' die Finger von dem Zeug,
das Du gerade machst. -- Michael Winklhofer in d.a.e.auktionshaeuser

Re: Problems with EDE

[Chong Yidong]

Sascha Wilde <wilde@sha-bang.de> writes:

> Yet another one:
> ede-make-dist does not work for ede automake projects:
>
>   -*- mode: compilation; default-directory: "/tmp/cedet-test1/" -*-
>   Compilation started at Thu Oct  8 22:52:13
>
>   make -f /tmp/cedet-test1/Makefile.am dist
>   make: *** No rule to make target `dist'.  Stop.
>
>   Compilation exited abnormally with code 2 at Thu Oct  8 22:52:13
>
> Using the Makefile.am is obviously wrong.  The actual Makefile contains
> an working dist target.

This is a bug in project-make-dist (the filename comparison forgets that
ede-proj-dist-makefile returns a full filename).  I've checked in a fix
into the trunk.

Eric, here's a patch for your tree (it also includes a stylistic
correction, to use expand-file-name instead of concat to generate full
filenames).


* cedet/ede/ede-proj.el (project-make-dist, project-compile-project):
Fix filename test.
(ede-proj-dist-makefile): Use expand-file-name instead of concat
to expand file names.

*** cedet/ede/ede-proj.el.~1.62.~	2009-08-18 19:56:57.000000000 -0400
--- cedet/ede/ede-proj.el	2009-10-08 18:12:20.000000000 -0400
***************
*** 453,459 ****
  	     (not (y-or-n-p "Dist file already exists.  Rebuild? ")))
  	(error "Try `ede-update-version' before making a distribution"))
      (ede-proj-setup-buildenvironment this)
!     (if (string= pm "Makefile.am") (setq pm "Makefile"))
      (compile (concat ede-make-command " -f " pm " dist"))
      ))
  
--- 453,461 ----
  	     (not (y-or-n-p "Dist file already exists.  Rebuild? ")))
  	(error "Try `ede-update-version' before making a distribution"))
      (ede-proj-setup-buildenvironment this)
!     (if (string= (file-name-nondirectory pm) "Makefile.am")
! 	(setq pm (expand-file-name "Makefile"
! 				   (file-name-directory pm))))
      (compile (concat ede-make-command " -f " pm " dist"))
      ))
  
***************
*** 470,476 ****
    (let ((pm (ede-proj-dist-makefile proj))
  	(default-directory (file-name-directory (oref proj file))))
      (ede-proj-setup-buildenvironment proj)
!     (if (string= pm "Makefile.am") (setq pm "Makefile"))
      (compile (concat ede-make-command" -f " pm " all"))))
  
  ;;; Target type specific compilations/debug
--- 472,480 ----
    (let ((pm (ede-proj-dist-makefile proj))
  	(default-directory (file-name-directory (oref proj file))))
      (ede-proj-setup-buildenvironment proj)
!     (if (string= (file-name-nondirectory pm) "Makefile.am")
! 	(setq pm (expand-file-name "Makefile"
! 				   (file-name-directory pm))))
      (compile (concat ede-make-command" -f " pm " all"))))
  
  ;;; Target type specific compilations/debug
***************
*** 599,609 ****
  	 (concat (file-name-directory (oref this file))
  		 "Makefile.am"))
  	((eq (oref this makefile-type) 'Makefile.in)
! 	 (concat (file-name-directory (oref this file))
! 		 "Makefile.in"))
  	((object-assoc "Makefile" 'makefile (oref this targets))
! 	 (concat (file-name-directory (oref this file))
! 		 "Makefile"))
  	(t
  	 (let ((targets (oref this targets)))
  	   (while (and targets
--- 603,613 ----
  	 (concat (file-name-directory (oref this file))
  		 "Makefile.am"))
  	((eq (oref this makefile-type) 'Makefile.in)
! 	 (expand-file-name "Makefile.in"
! 			   (file-name-directory (oref this file))))
  	((object-assoc "Makefile" 'makefile (oref this targets))
! 	 (expand-file-name "Makefile"
! 			   (file-name-directory (oref this file))))
  	(t
  	 (let ((targets (oref this targets)))
  	   (while (and targets
***************
*** 612,619 ****
  			     'ede-proj-target-makefile)))
  	     (setq targets (cdr targets)))
  	   (if targets (oref (car targets) makefile)
! 	     (concat (file-name-directory (oref this file))
! 		     "Makefile"))))))
  
  (defun ede-proj-regenerate ()
    "Regenerate Makefiles for and edeproject project."
--- 616,623 ----
  			     'ede-proj-target-makefile)))
  	     (setq targets (cdr targets)))
  	   (if targets (oref (car targets) makefile)
! 	     (expand-file-name "Makefile"
! 			       (file-name-directory (oref this file))))))))
  
  (defun ede-proj-regenerate ()
    "Regenerate Makefiles for and edeproject project."

Re: Problems with EDE

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Thu, 08 Oct 2009 18:15:55 -0400
> Cc: Sascha Wilde <wilde@sha-bang.de>, emacs-devel@gnu.org
> 
> !     (if (string= (file-name-nondirectory pm) "Makefile.am")
> ! 	(setq pm (expand-file-name "Makefile"
> ! 				   (file-name-directory pm))))

Possible trouble alert!  Comparing file names with string= might mean
trouble on case-insensitive filesystems, if one happens to have
something like "makefile.am" by some chance.

I didn't yet have time to play with CEDET, so maybe the problem does
not exist.  Would someone please check?

Re: Problems with EDE

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> Yet another one:
>> ede-make-dist does not work for ede automake projects:
[...]
> This is a bug in project-make-dist (the filename comparison forgets that
> ede-proj-dist-makefile returns a full filename).  I've checked in a fix
> into the trunk.

Thanks. That fixed it for me!

And made me discover the next problem:
The generated configure script as packed into the dist tar depends on
Project.ede, but that isn't part of the distribution:

$ tar xzvf cedettest/ede-test-1.0.tar.gz
$ cd ede-test-1.0
$ ./configure
configure: error: cannot find sources (Project.ede) in . or ..

I'm not sure which is the bug, the dependency or that Project.ede is not
distributed...

cheers
sascha
-- 
Sascha Wilde

I've always figured UNIX is a utility to be run under emacs.
	-- Charles R. Martin

Re: Problems with EDE

[Eric M. Ludlam]

On Fri, 2009-10-09 at 14:15 +0200, Sascha Wilde wrote:
> Chong Yidong <cyd@stupidchicken.com> wrote:
> > Sascha Wilde <wilde@sha-bang.de> writes:
> >
> >> Yet another one:
> >> ede-make-dist does not work for ede automake projects:
> [...]
> > This is a bug in project-make-dist (the filename comparison forgets that
> > ede-proj-dist-makefile returns a full filename).  I've checked in a fix
> > into the trunk.
> 
> Thanks. That fixed it for me!
> 
> And made me discover the next problem:
> The generated configure script as packed into the dist tar depends on
> Project.ede, but that isn't part of the distribution:
> 
> $ tar xzvf cedettest/ede-test-1.0.tar.gz
> $ cd ede-test-1.0
> $ ./configure
> configure: error: cannot find sources (Project.ede) in . or ..
> 
> I'm not sure which is the bug, the dependency or that Project.ede is not
> distributed...

I checked in some changes in the CEDET repository to make this work.  I
also fixed a problem it had with automake projects with more than one
directory level.

I hadn't thought to put a test of the "dist" into my test suite.  This
seems like a good idea.

Thanks
Eric

Re: Problems with EDE

[Sascha Wilde]

"Eric M. Ludlam" <eric@siege-engine.com> wrote:
[missing Project.ede in distribution archive]
> I checked in some changes in the CEDET repository to make this work.  I
> also fixed a problem it had with automake projects with more than one
> directory level.

Thanks a lot for this and all the other improvements you did.  I can't
test them though, as I'm using GNU-Emacs CVS HEAD, not your CEDET repo.

Who feels in charge to merge this changes into HEAD?
I'll happily test them once they arrived there.  ;-)

cheers
sascha
-- 
Sascha Wilde  :  "The PROPER way to handle HTML postings is to cancel
the article, then hire a hitman to kill the poster, his wife and kids,
and fuck his dog and smash his computer into little bits. Anything
more is just extremism."  -- Paul Tomblin

Re: Problems with EDE

[Chong Yidong]

Sascha Wilde <wilde@sha-bang.de> writes:

> Who feels in charge to merge this changes into HEAD?
> I'll happily test them once they arrived there.  ;-)

I'll do the merge over the weekend.

Re: Problems with EDE

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> Who feels in charge to merge this changes into HEAD?
>> I'll happily test them once they arrived there.  ;-)
>
> I'll do the merge over the weekend.

Done.

Re: Problems with EDE

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
>> Sascha Wilde <wilde@sha-bang.de> writes:
>>
>>> Who feels in charge to merge this changes into HEAD?
>>> I'll happily test them once they arrived there.  ;-)
>>
>> I'll do the merge over the weekend.
>
> Done.

Thanks a lot!

On a quick test I can confirm, that
- Sharedobject targets in make-projects build now with libtool
  (which works as expected)
- Annoying re-asking for creation of existing supplemental files has
  gone.
- Make distribution works as expected.
- Building from the created distribution tars works.

Thanks to Eric and Chong for fixing all this.  Next I'll switch to bug
reporting mode again.  ;-)

cheers
sascha 
-- 
Sascha Wilde
    "Liebet eure Feinde, vielleicht schadet das ihrem Ruf" 
    (Stanislaw Jerzy Lec)

Re: Problems with EDE

[Eric M. Ludlam]

Thanks for the patch.  I have applied it to my repository.

I've added cedet/cedet-ediff.el to my repository which lets me diff
between the Emacs CVS repository and the CEDET repository more easilly,
which allowed me to also get the spelling fix someone checked in.

If you would like to just diff the Emacs repository, I'll be able to use
my new tool to get your patch merged into my repository more easily now.

Thanks
Eric

On Thu, 2009-10-08 at 18:15 -0400, Chong Yidong wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
> 
> > Yet another one:
> > ede-make-dist does not work for ede automake projects:
> >
> >   -*- mode: compilation; default-directory: "/tmp/cedet-test1/" -*-
> >   Compilation started at Thu Oct  8 22:52:13
> >
> >   make -f /tmp/cedet-test1/Makefile.am dist
> >   make: *** No rule to make target `dist'.  Stop.
> >
> >   Compilation exited abnormally with code 2 at Thu Oct  8 22:52:13
> >
> > Using the Makefile.am is obviously wrong.  The actual Makefile contains
> > an working dist target.
> 
> This is a bug in project-make-dist (the filename comparison forgets that
> ede-proj-dist-makefile returns a full filename).  I've checked in a fix
> into the trunk.
> 
> Eric, here's a patch for your tree (it also includes a stylistic
> correction, to use expand-file-name instead of concat to generate full
> filenames).
> 
> 
> * cedet/ede/ede-proj.el (project-make-dist, project-compile-project):
> Fix filename test.
> (ede-proj-dist-makefile): Use expand-file-name instead of concat
> to expand file names.
> 
> *** cedet/ede/ede-proj.el.~1.62.~	2009-08-18 19:56:57.000000000 -0400
> --- cedet/ede/ede-proj.el	2009-10-08 18:12:20.000000000 -0400
> ***************
> *** 453,459 ****
>   	     (not (y-or-n-p "Dist file already exists.

Re: Problems with EDE

[Sascha Wilde]

And two more problems...  ;-)

With target type "sharedobject" ede projects build shared libraries.
Using an ede automake project building such an target fails in tow
respects:

1. Setup of the autotools infrastructure:

    -*- mode: compilation; default-directory: "/tmp/cedettest/" -*-
    Compilation started at Fri Oct  9 14:23:30

    aclocal;automake --add-missing;autoreconf;
    configure.ac:8: required file `./ltmain.sh' not found
    configure.ac:8: required file `./ltmain.sh' not found
    autoreconf: automake failed with exit status: 1

    Compilation exited abnormally with code 1 at Fri Oct  9 14:24:03

   This might be actually due to an automake bug, because IMO 
   `automake --add-missing' should generate ltmain.sh -- anyway it
   doesn't (tested with automake 1.10.1 on Debian Lenny).

   Calling libtoolize manually fixes this.

2. After hot-fixing (1) compilation still fails:

    make: *** No rule to make target `libfoo.so'.  Stop

   This is due the fact, that using libtool/automake the target for the
   library is libfoo.la, not libfoo.so.

   Manual compile with `M-x compile RET make libfoo.la' works.

cheers
sascha
-- 
Sascha Wilde : xedit? Das sieht zwar wie vi aus als könne es nix, aber im
             : Gegensatz zu vi kann es wirklich nix und nix ist noch geschönt!
             : (Michael Core in dafc)

Re: Problems with EDE

[Sascha Wilde]

Sascha Wilde <wilde@sha-bang.de> wrote:
> With target type "sharedobject" ede projects build shared libraries.
> Using an ede automake project building such an target fails in tow
> respects:

Building sharedobjects in ede make projects fails, too:

    -*- mode: compilation; default-directory: "/tmp/cedet-test5/" -*-
    Compilation started at Fri Oct  9 14:39:45

    make -f Makefile libfoo.so
    gcc    -march=athlon-xp -O3 -c greet.c
    gcc -march=athlon-xp -O3  -L. -o libfoo.so greet.o
    /usr/lib/crt1.o: In function `_start':
    (.text+0x18): undefined reference to `main'
    collect2: ld returned 1 exit status
    make: *** [libfoo.so] Error 1

    Compilation exited abnormally with code 2 at Fri Oct  9 14:39:45

sascha
-- 
Sascha Wilde

"There is no reason why anyone would want a computer in their home"
Ken Olson, DEC, 1977

Re: Problems with EDE

[Eric M. Ludlam]

Hi Sascha,

I appreciate the investigations you've been doing.  So you know, the
only things I can guarantee to work are the tests running in the CEDET
repository.  They are in cedet/tests/.  This test suite creates code off
in /tmp and runs against Make and Automake targets.

Ideally, when I fix things, I try to add tests for them.  I only caught
the testing bug for CEDET long after I wrote most of EDE, so there is
much left to do here.

I'm interested in working with you to get these types of issues fixed,
but I know I won't have much time till after the Punkin Chunk which is
Nov 6/7/8 of this year.

Thanks
Eric

On Fri, 2009-10-09 at 14:42 +0200, Sascha Wilde wrote:
> Sascha Wilde <wilde@sha-bang.de> wrote:
> > With target type "sharedobject" ede projects build shared libraries.
> > Using an ede automake project building such an target fails in tow
> > respects:
> 
> Building sharedobjects in ede make projects fails, too:
> 
>     -*- mode: compilation; default-directory: "/tmp/cedet-test5/" -*-
>     Compilation started at Fri Oct  9 14:39:45
> 
>     make -f Makefile libfoo.so
>     gcc    -march=athlon-xp -O3 -c greet.c
>     gcc -march=athlon-xp -O3  -L. -o libfoo.so greet.o
>     /usr/lib/crt1.o: In function `_start':
>     (.text+0x18): undefined reference to `main'
>     collect2: ld returned 1 exit status
>     make: *** [libfoo.so] Error 1
> 
>     Compilation exited abnormally with code 2 at Fri Oct  9 14:39:45
> 
> sascha

Re: Problems with EDE

[Sascha Wilde]

"Eric M. Ludlam" <eric@siege-engine.com> wrote:
[...]
> I'm interested in working with you to get these types of issues fixed,
> but I know I won't have much time till after the Punkin Chunk which is
> Nov 6/7/8 of this year.

No problem.  Just drop me a line when you are available again.

cheers
sascha
-- 
Sascha Wilde
Hauptfunktion einer GUI ist es IMHO, die dadurch verlorene Zeit durch
einen höheren Spaß-Faktor zu kompensieren. Essentiell ein
Computerspiel.  --  Rainer Weikusat in d.c.o.u.d

Re: Problems with EDE

[Eric M. Ludlam]

On Fri, 2009-10-09 at 14:42 +0200, Sascha Wilde wrote:
> Sascha Wilde <wilde@sha-bang.de> wrote:
> > With target type "sharedobject" ede projects build shared libraries.
> > Using an ede automake project building such an target fails in tow
> > respects:
> 
> Building sharedobjects in ede make projects fails, too:
> 
>     -*- mode: compilation; default-directory: "/tmp/cedet-test5/" -*-
>     Compilation started at Fri Oct  9 14:39:45
> 
>     make -f Makefile libfoo.so
>     gcc    -march=athlon-xp -O3 -c greet.c
>     gcc -march=athlon-xp -O3  -L. -o libfoo.so greet.o
>     /usr/lib/crt1.o: In function `_start':
>     (.text+0x18): undefined reference to `main'
>     collect2: ld returned 1 exit status
>     make: *** [libfoo.so] Error 1
> 

I have checked in changes to the CEDET repository for the following:

* shared objects for Make now use libtool by default.
* Found a set of arguments for C++ and libtool that seem to work.
* updated my tests to exercise this case for C++.

One caveat is that you can't mix libtool and other C++ targets code in
the same Project due to some pretty basic conflicts with the inference
rules created.

I'm also not sure about the C version.

In any case, any assistance folks can provide on how best to use libtool
in these cases would be appreciated, as I am not an expert in this area.

Thanks
Eric

Re: Problems with EDE

[Andreas Schwab]

Sascha Wilde <wilde@sha-bang.de> writes:

> 1. Setup of the autotools infrastructure:
>
>     -*- mode: compilation; default-directory: "/tmp/cedettest/" -*-
>     Compilation started at Fri Oct  9 14:23:30
>
>     aclocal;automake --add-missing;autoreconf;

That should be replaced by a single call to "autoreconf -i".

>    This might be actually due to an automake bug, because IMO 
>    `automake --add-missing' should generate ltmain.sh -- anyway it
>    doesn't (tested with automake 1.10.1 on Debian Lenny).

ltmain.sh is part of libtool, not automake.

>    Calling libtoolize manually fixes this.

Since autoreconf is not called with --install, it won't run libtoolize.

Andreas.

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

Re: Problems with EDE

[Chong Yidong]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> 1. Setup of the autotools infrastructure:
>>
>>     -*- mode: compilation; default-directory: "/tmp/cedettest/" -*-
>>     Compilation started at Fri Oct  9 14:23:30
>>
>>     aclocal;automake --add-missing;autoreconf;
>
> That should be replaced by a single call to "autoreconf -i".
>
>>    This might be actually due to an automake bug, because IMO 
>>    `automake --add-missing' should generate ltmain.sh -- anyway it
>>    doesn't (tested with automake 1.10.1 on Debian Lenny).
>
> ltmain.sh is part of libtool, not automake.
>
>>    Calling libtoolize manually fixes this.
>
> Since autoreconf is not called with --install, it won't run libtoolize.

Sascha, could you try with this patch?

*** emacs/lisp/cedet/ede/pconf.el.~1.3.~	2009-10-03 13:42:57.000000000 -0400
--- emacs/lisp/cedet/ede/pconf.el	2009-10-09 14:07:14.000000000 -0400
***************
*** 99,111 ****
         (ede-map-targets this 'ede-proj-tweak-autoconf)))
      ;; Now save
      (save-buffer)
!     ;; Verify aclocal
!     (setq postcmd "aclocal;")
!     ;; Always add missing files as needed.
!     (setq postcmd (concat postcmd "automake --add-missing;"))
! 
!     ;; Always do autoreconf
!     (setq postcmd (concat postcmd "autoreconf;"))
      ;; Verify a bunch of files that are required by automake.
      (ede-proj-configure-test-required-file this "AUTHORS")
      (ede-proj-configure-test-required-file this "NEWS")
--- 99,105 ----
         (ede-map-targets this 'ede-proj-tweak-autoconf)))
      ;; Now save
      (save-buffer)
!     (setq postcmd "autoreconf -i;")
      ;; Verify a bunch of files that are required by automake.
      (ede-proj-configure-test-required-file this "AUTHORS")
      (ede-proj-configure-test-required-file this "NEWS")

Diff finished.  Fri Oct  9 14:08:11 2009

Re: Problems with EDE

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>> Sascha Wilde <wilde@sha-bang.de> writes:
>>
>>> 1. Setup of the autotools infrastructure:
>>>
>>>     -*- mode: compilation; default-directory: "/tmp/cedettest/" -*-
>>>     Compilation started at Fri Oct  9 14:23:30
>>>
>>>     aclocal;automake --add-missing;autoreconf;
>>
>> That should be replaced by a single call to "autoreconf -i".
[...]
> Sascha, could you try with this patch?

Yes, this works for me.  The libtool files are now created as expected.

It still tries to compile the wrong target (libfoo.so instead of
libfoo.la) but that wasn't subject of your patch.

cheers
sascha
-- 
Sascha Wilde

If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

Re: Problems with EDE

[Sascha Wilde]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

Sascha Wilde <wilde@sha-bang.de> wrote:
> It still tries to compile the wrong target (libfoo.so instead of
> libfoo.la) but that wasn't subject of your patch.

This path fixes the target issue for me:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 717 bytes --]

diff -r a31c0d5082f6 lisp/cedet/ede/proj-shared.el
--- a/lisp/cedet/ede/proj-shared.el	Fri Oct 09 15:49:09 2009 +0200
+++ b/lisp/cedet/ede/proj-shared.el	Fri Oct 09 21:11:54 2009 +0200
@@ -150,7 +150,10 @@
   "Return the name of the main target for THIS target."
   ;; We need some platform gunk to make the .so change to .sl, or .a,
   ;; depending on the platform we are going to compile against.
-  (concat "lib" (ede-name this) ".so"))
+  (concat "lib" (ede-name this)   
+	  (if (eq (oref (ede-target-parent this) makefile-type) 'Makefile.am)
+	      ".la"
+	    ".so")))
 
 (defmethod ede-proj-makefile-sourcevar ((this ede-proj-target-makefile-shared-object))
   "Return the variable name for THIS's sources."

[-- Attachment #3: Type: text/plain, Size: 113 bytes --]


cheers
sascha
-- 
Sascha Wilde 
Hi! I'm a .signature *virus*! Copy me into your ~/.signature to help me spread!

Re: Problems with EDE

[Chong Yidong]

Sascha Wilde <wilde@sha-bang.de> writes:

> This path fixes the target issue for me:
>
> diff -r a31c0d5082f6 lisp/cedet/ede/proj-shared.el
> --- a/lisp/cedet/ede/proj-shared.el	Fri Oct 09 15:49:09 2009 +0200
> +++ b/lisp/cedet/ede/proj-shared.el	Fri Oct 09 21:11:54 2009 +0200
> @@ -150,7 +150,10 @@
>    "Return the name of the main target for THIS target."
>    ;; We need some platform gunk to make the .so change to .sl, or .a,
>    ;; depending on the platform we are going to compile against.
> -  (concat "lib" (ede-name this) ".so"))
> +  (concat "lib" (ede-name this)
> +	  (if (eq (oref (ede-target-parent this) makefile-type) 'Makefile.am)
> +	      ".la"
> +	    ".so")))

Is this generally right, though?  As the comment notes, there may be
situations where .a is the correct extension, no?

Re: Problems with EDE

[Sascha Wilde]

Chong Yidong <cyd@stupidchicken.com> wrote:
> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> This path fixes the target issue for me:
>>
>> diff -r a31c0d5082f6 lisp/cedet/ede/proj-shared.el
>> --- a/lisp/cedet/ede/proj-shared.el	Fri Oct 09 15:49:09 2009 +0200
>> +++ b/lisp/cedet/ede/proj-shared.el	Fri Oct 09 21:11:54 2009 +0200
>> @@ -150,7 +150,10 @@
>>    "Return the name of the main target for THIS target."
>>    ;; We need some platform gunk to make the .so change to .sl, or .a,
>>    ;; depending on the platform we are going to compile against.
>> -  (concat "lib" (ede-name this) ".so"))
>> +  (concat "lib" (ede-name this)
>> +	  (if (eq (oref (ede-target-parent this) makefile-type) 'Makefile.am)
>> +	      ".la"
>> +	    ".so")))
>
> Is this generally right, though?  As the comment notes, there may be
> situations where .a is the correct extension, no?

In case of automake/libtool it shouldn't matter as libtool knows the
dirty details of platform specific naming conventions.  You ask for the
meta file .la and get .so .sl .a .dyn or what ever you need.  So I'd
say: my code is portable.

For the case of make projects (the ".so" case in the above code) it's a
different story: there the .so is actually a bold assumption and wrong
on some platforms, but that was the case before my patch, too.  So the
comment only describes an todo.

Actually I would suggest to use libtool even for the ede make project
variant where possible, as trying to get things right for all possible
platforms would mean to duplicate the affords of libtool to great
extends.

sascha
-- 
Sascha Wilde : The most exciting phrase to hear in science, the one
             : that heralds new discoveries, is not "Eureka!" (I found
             : it!) but "That's funny ..." -- Isaac Asimov

Re: Problems with EDE

[Eric M. Ludlam]

On Fri, 2009-10-09 at 23:19 +0200, Sascha Wilde wrote:
> Chong Yidong <cyd@stupidchicken.com> wrote:
> > Sascha Wilde <wilde@sha-bang.de> writes:

> Actually I would suggest to use libtool even for the ede make project
> variant where possible, as trying to get things right for all possible
> platforms would mean to duplicate the affords of libtool to great
> extends.

There is libtool support for Make projects already, it is just not the
default.

The attached patch against my repository shows that you just need to
swap the order to make libtool the default.

I realize that there is more work to be done for this target type, in
terms of querying the compiler to figure out what the target name is,
but just doing this swap would let you experiment with it and see what
else needs to be done.

You could also customize the shared object target, and just select
libtool as the compiler you want to use instead of changing the code.

Eric
--------------------------

*** ede-proj-shared.el.~1.11.~	2009-10-09 15:49:22.000000000 -0400
--- ede-proj-shared.el	2009-10-13 22:39:18.000000000 -0400
***************
*** 34,43 ****
  ;;; Code:
  (defclass ede-proj-target-makefile-shared-object
    (ede-proj-target-makefile-program)
!   ((availablecompilers :initform (ede-gcc-shared-compiler
! 				  ede-gcc-libtool-shared-compiler
! 				  ede-g++-shared-compiler
  				  ede-g++-libtool-shared-compiler
  				  ))
     (ldflags :custom (repeat (string :tag "Libtool flag"))
  	    :documentation
--- 34,43 ----
  ;;; Code:
  (defclass ede-proj-target-makefile-shared-object
    (ede-proj-target-makefile-program)
!   ((availablecompilers :initform (ede-gcc-libtool-shared-compiler
! 				  ede-gcc-shared-compiler
  				  ede-g++-libtool-shared-compiler
+ 				  ede-g++-shared-compiler
  				  ))
     (ldflags :custom (repeat (string :tag "Libtool flag"))
  	    :documentation

Re: Problems with EDE

[Eric M. Ludlam]

I tried this patch in my test-suite and it worked for me also.

I very recently updated the autoconf stuff, prompted by needing better
test suites, and when I read about autoreconf, I tried it but did not
know about the -i option.  It does indeed simplify things a lot.

Eric

On Fri, 2009-10-09 at 14:08 -0400, Chong Yidong wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
> 
> > Sascha Wilde <wilde@sha-bang.de> writes:
> >
> >> 1. Setup of the autotools infrastructure:
> >>
> >>     -*- mode: compilation; default-directory: "/tmp/cedettest/" -*-
> >>     Compilation started at Fri Oct  9 14:23:30
> >>
> >>     aclocal;automake --add-missing;autoreconf;
> >
> > That should be replaced by a single call to "autoreconf -i".
> >
> >>    This might be actually due to an automake bug, because IMO 
> >>    `automake --add-missing' should generate ltmain.sh -- anyway it
> >>    doesn't (tested with automake 1.10.1 on Debian Lenny).
> >
> > ltmain.sh is part of libtool, not automake.
> >
> >>    Calling libtoolize manually fixes this.
> >
> > Since autoreconf is not called with --install, it won't run libtoolize.
> 
> Sascha, could you try with this patch?
> 
> *** emacs/lisp/cedet/ede/pconf.el.~1.3.~	2009-10-03 13:42:57.000000000 -0400
> --- emacs/lisp/cedet/ede/pconf.el	2009-10-09 14:07:14.000000000 -0400
> ***************
> *** 99,111 ****
>          (ede-map-targets this 'ede-proj-tweak-autoconf)))
>       ;; Now save
>       (save-buffer)
> !     ;; Verify aclocal
> !     (setq postcmd "aclocal;")
> !     ;; Always add missing files as needed.
> !     (setq postcmd (concat postcmd "automake --add-missing;"))
> ! 
> !     ;; Always do autoreconf
> !     (setq postcmd (concat postcmd "autoreconf;"))
>       ;; Verify a bunch of files that are required by automake.
>       (ede-proj-configure-test-required-file this "AUTHORS")
>       (ede-proj-configure-test-required-file this "NEWS")
> --- 99,105 ----
>          (ede-map-targets this 'ede-proj-tweak-autoconf)))
>       ;; Now save
>       (save-buffer)
> !     (setq postcmd "autoreconf -i;")
>       ;; Verify a bunch of files that are required by automake.
>       (ede-proj-configure-test-required-file this "AUTHORS")
>       (ede-proj-configure-test-required-file this "NEWS")
> 
> Diff finished.  Fri Oct  9 14:08:11 2009

Re: Problems with EDE

[Chong Yidong]

Sascha Wilde <wilde@sha-bang.de> writes:

> - C-x b test.c RET
> - C-c . c
>
> Asks again for all files AUTHORS, NEWS, README and Changelog if they
> should be created despite the fact that they are already there.  Even
> more: it readds and thereby duplicates the automatic generated entries
> (for AUTHORS and NEWS).
>
> Answering no to any of there "create foo" questions immediately
> terminates the whole ede build process, which IMO is a bug, too.

It is indeed obnoxious for EDE to create the file *first*, then asks the
user "I created this file, OK?"  It should ask first.  I'll see what I
can do to improve this.

Re: CEDET merge

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> Short term, you could get the templates from CEDET CVS in
> cedet/srecode/templates and cedet/ede/templates and place them in
> equivalent locations just under srecode.el and ede.el to get past this
> until there is a home for SRecode Templates in Emacs.

I've added the SRecode templates to etc/srecode.

Building in EDE should now work---provided Semantic is enabled from the
start.  We still need to provide a way for SRecode to call Semantic to
parse the template buffer, when Semantic is not currently enabled (this
functionality will be useful for other parts of Emacs too).

Re: CEDET merge

[Eric M. Ludlam]

On Sat, 2009-10-03 at 16:10 -0400, Chong Yidong wrote:
> "Eric M. Ludlam" <eric@siege-engine.com> writes:
> 
> > Short term, you could get the templates from CEDET CVS in
> > cedet/srecode/templates and cedet/ede/templates and place them in
> > equivalent locations just under srecode.el and ede.el to get past this
> > until there is a home for SRecode Templates in Emacs.
> 
> I've added the SRecode templates to etc/srecode.
> 
> Building in EDE should now work---provided Semantic is enabled from the
> start.  We still need to provide a way for SRecode to call Semantic to
> parse the template buffer, when Semantic is not currently enabled (this
> functionality will be useful for other parts of Emacs too).

Semantic can parse files even if all the other related utilities are
never enabled.  As long as srecode-template-mode sets up the parser info
itself, and not in the new "semantic-mode", then it can use the Semantic
API to parse buffers during template compilation without interfering
with someones desire to not enable Semantic parsing and utilities in
other files, like C++ mode.

Eric

Re: CEDET merge

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

>> Building in EDE should now work---provided Semantic is enabled from the
>> start.  We still need to provide a way for SRecode to call Semantic to
>> parse the template buffer, when Semantic is not currently enabled (this
>> functionality will be useful for other parts of Emacs too).
>
> Semantic can parse files even if all the other related utilities are
> never enabled.  As long as srecode-template-mode sets up the parser info
> itself, and not in the new "semantic-mode", then it can use the Semantic
> API to parse buffers during template compilation without interfering
> with someones desire to not enable Semantic parsing and utilities in
> other files, like C++ mode.

How about this:

In the Emacs-integrated version of Semantic, we semantic-new-buffer-fcn
so that it runs the mode-dependent parser setup functions before doing
anything else.  This is as opposed to running the parser setup functions
from the mode-hooks, as your upstream code does, or in the body of
semantic-mode, as the Emacs version currently does.  So, when srecode
calls semantic-new-buffer-fcn, the right setup will take place.

What do you think?

Re: CEDET merge

[Eric M. Ludlam]

On Sat, 2009-10-03 at 21:44 -0400, Chong Yidong wrote:
> "Eric M. Ludlam" <eric@siege-engine.com> writes:
> 
> >> Building in EDE should now work---provided Semantic is enabled from the
> >> start.  We still need to provide a way for SRecode to call Semantic to
> >> parse the template buffer, when Semantic is not currently enabled (this
> >> functionality will be useful for other parts of Emacs too).
> >
> > Semantic can parse files even if all the other related utilities are
> > never enabled.  As long as srecode-template-mode sets up the parser info
> > itself, and not in the new "semantic-mode", then it can use the Semantic
> > API to parse buffers during template compilation without interfering
> > with someones desire to not enable Semantic parsing and utilities in
> > other files, like C++ mode.
> 
> How about this:
> 
> In the Emacs-integrated version of Semantic, we semantic-new-buffer-fcn
> so that it runs the mode-dependent parser setup functions before doing
> anything else.  This is as opposed to running the parser setup functions
> from the mode-hooks, as your upstream code does, or in the body of
> semantic-mode, as the Emacs version currently does.  So, when srecode
> calls semantic-new-buffer-fcn, the right setup will take place.
> 
> What do you think?

I think I have failed to understand the above.

Does the Emacs integrated CEDET no longer use mode-local to call
semantic-new-buffer-fcn?  That could be good news.  The hooks available
in Emacs to detect a change in major mode for mode-local.el have been
challenging to get right, and I think they can still sometimes not work
right.

I did fail to explain in my paragraph above that mode-local.el would
need to be active for any files to be parse-able.  I was referring to
semanticdb, and semantic-idle features do not need to be enabled for
SRecode to be able to parse/compile template files.  As you point out,
the semantic-new-buffer-fcn does need to run, and the mode-local
settings need to be active for semantic to parse stuff.

Is there a desire to have srecode parse/compile template files while
leaving mode-local inactive?  Does mode-local get activated with
semantic-mode?  Perhaps I should check out a fresh copy of 
Emacs to better understand.  I've been worried of doing so because I
know I'll then need to also figure out how to enable my CEDET distro
shadowing the Emacs version, and I don't really want to do that work.

Eric

Re: CEDET merge

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> Does the Emacs integrated CEDET no longer use mode-local to call
> semantic-new-buffer-fcn?  That could be good news.  The hooks available
> in Emacs to detect a change in major mode for mode-local.el have been
> challenging to get right, and I think they can still sometimes not work
> right.

No, semantic-new-buffer-fcn is still called from mode-local.  I was
proposing to move the parser setup functions from the mode hooks into
semantic-new-buffer-fcn.  That way, we can parse an existing buffer
(e.g., a buffer that already exists by the time Semantic is enabled, or
a buffer that Srecode wants to parse without enabling Semantic
globally), simply by calling semantic-new-buffer-fcn.

Re: CEDET merge

[Miles Bader]

Chong Yidong <cyd@stupidchicken.com> writes:
> 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.

(1)
"M-x semantic-mode" works, but if I do "M-x global-ede-mode", I get the
following error:

   Cannot open load file: ede/makefile-edit

If there are already source-file buffers when I do M-x global-ede-mode,
then I the error immediately, otherwise, it happens when I visit a
source file or directory.

I tried "make bootstrap" etc, with no improvement.

(2)
I get the following error with semantic-mode:

   (a) visit the following source file:

---- cut here ----
#include <stdio.h>

int main ()
{
  printf ("hello world\n");
  return 0;
}
---- cut here ----

   (b) do M-x semantic-mode

   (c) position point after "printf"

   (d) use the command: "C-c , j"
       (I don't even know what that command does, but it gets an error...)

   (e) I get the following error/backtrace:

Debugger entered--Lisp error: (wrong-type-argument syntax-table-p nil)          
  set-syntax-table(nil)                                                         
  semantic-ctxt-current-symbol-default(nil)                                     
  semantic-ctxt-current-symbol()                                                
  semantic-ctxt-current-thing()                                                 
  semantic-complete-default-to-tag(nil)                                         
  semantic-complete-read-tag-engine([object semantic-collector-buffer-deep "Sym$
  semantic-complete-read-tag-buffer-deep("Symbol: ")                            
  semantic-complete-jump-local()                                                
  call-interactively(semantic-complete-jump-local nil nil)                      

-miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: CEDET merge

[Eric M. Ludlam]

On Thu, 2009-10-01 at 12:58 +0900, Miles Bader wrote:
> Chong Yidong <cyd@stupidchicken.com> writes:
> (2)
> I get the following error with semantic-mode:
> 
>    (a) visit the following source file:
> 
> ---- cut here ----
> #include <stdio.h>
> 
> int main ()
> {
>   printf ("hello world\n");
>   return 0;
> }
> ---- cut here ----
> 
>    (b) do M-x semantic-mode
> 
>    (c) position point after "printf"
> 
>    (d) use the command: "C-c , j"
>        (I don't even know what that command does, but it gets an error...)
> 
>    (e) I get the following error/backtrace:
> 
> Debugger entered--Lisp error: (wrong-type-argument syntax-table-p nil)          
>   set-syntax-table(nil)                                                         
>   semantic-ctxt-current-symbol-default(nil)                                     
>   semantic-ctxt-current-symbol()                                                
>   semantic-ctxt-current-thing()                                                 
>   semantic-complete-default-to-tag(nil)                                         
>   semantic-complete-read-tag-engine([object semantic-collector-buffer-deep "Sym$
>   semantic-complete-read-tag-buffer-deep("Symbol: ")                            
>   semantic-complete-jump-local()                                                
>   call-interactively(semantic-complete-jump-local nil nil)                      

I haven't had the opportunity to use the Emacs/CEDET merged version, but
I can provide some help here.  The Semantic configuration was setup to
be done in a .emacs file, or very early on, and all the necessary setup
is done in mode hooks after that.  If you load in a C file, then turn on
Semantic, then your current buffer will not have the right variables
setup.  In this case, it is a variable that tweaks the syntax table.

I think the right order would be

M-x semantic-mode

;; create the file

continue with above script.

I would guess that the new semantic-mode should either warn on
pre-existing buffers, or find a way to apply itself to pre-existing
buffers.  The standalone CEDET install works around this by the file
that loads CEDET doing these installs in your .emacs file.  The
assumption being that if you installed CEDET, you want this stuff on,
which is not the case for Emacs.

Eric

Re: CEDET merge

[Chong Yidong]

"Eric M. Ludlam" <eric@siege-engine.com> writes:

> I would guess that the new semantic-mode should either warn on
> pre-existing buffers, or find a way to apply itself to pre-existing
> buffers.

This should be easy to implement, but I have not had time to do it yet.

Re: CEDET merge

[Phil Hagelberg]

Chong Yidong <cyd@stupidchicken.com> 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.

The doc header at the top of pulse.el mentions the function
pulse-enable-integration-advice, which has been removed presumably to
conform to Emacs "no advice in core" standard. But the comment has not
been updated.

The patch below fixes this.

-Phil

diff --git a/lisp/cedet/pulse.el b/lisp/cedet/pulse.el
index c7ece45..7977104 100644
--- a/lisp/cedet/pulse.el
+++ b/lisp/cedet/pulse.el
@@ -27,11 +27,6 @@
 ;; highlighted briefly.  This adds a gentle pulsing style to the text
 ;; decorated this way.
 ;;
-;; Useful user functions:
-;;
-;; `pulse-enable-integration-advice' - Turn on advice to make various
-;;      Emacs commands pulse, such as `goto-line', or `find-tag'.
-;;
 ;; The following are useful entry points:
 ;;
 ;; `pulse' - Cause `pulse-highlight-face' to shift toward background color.

Re: CEDET merge

[Chong Yidong]

> The doc header at the top of pulse.el mentions the function
> pulse-enable-integration-advice, which has been removed presumably to
> conform to Emacs "no advice in core" standard. But the comment has not
> been updated.
>
> The patch below fixes this.

Thanks, applied.

Re: CEDET merge

[Eric M. Ludlam]

On Wed, 2009-10-07 at 01:37 -0400, Chong Yidong wrote:
> > The doc header at the top of pulse.el mentions the function
> > pulse-enable-integration-advice, which has been removed presumably to
> > conform to Emacs "no advice in core" standard. But the comment has not
> > been updated.
> >
> > The patch below fixes this.
> 
> Thanks, applied.
> 

While the feature specified which allows fcns such as goto-line to do a
pulse after the line has been gone to is certainly superfluous (I don't
use them), what would be he recommended way to make it possible to make
such changes w/out using advice?

I recognize that `beginning-of-defun' and friends discussed earlier
would be the model, but I can't imagine adding such replacement features
into every user facing command just in case.

For the pulse case, is there an interest in snazzing up the original
function list with pulsing, or is it too gratuitous to even contemplate?

Eric