* bootstrap fails
[not found] <E1JEXu8-0004C3-Cy@cvs.savannah.gnu.org>
@ 2008-01-15 0:03 ` Katsumi Yamaoka
2008-01-16 0:13 ` bootstrap fails AND how about fixing the byte-compiler? Alan Mackenzie
0 siblings, 1 reply; 12+ messages in thread
From: Katsumi Yamaoka @ 2008-01-15 0:03 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
>>>>> Alan Mackenzie wrote:
> Log message:
> * progmodes/cc-vars.el (c-constant-symbol): New function which supersedes
> c-const-symbol. During a customize-.. call it enables an element of
> (e.g.) c-hanging-braces alist to have its name displayed, even when the
> default value of c-h-b etc. doesn't include the elemnt. Replace uses of
> the old function by the new.
By this change Emacs bootstrap fails. The `c-constant-symbol'
function seems to have to be surrounded by `eval-and-compile'.
Regards,
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bootstrap fails AND how about fixing the byte-compiler?
2008-01-15 0:03 ` bootstrap fails Katsumi Yamaoka
@ 2008-01-16 0:13 ` Alan Mackenzie
2008-01-16 0:58 ` Miles Bader
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Alan Mackenzie @ 2008-01-16 0:13 UTC (permalink / raw)
To: Katsumi Yamaoka, David Reitter; +Cc: emacs-devel
Hi, David and Katsumi!
On Tue, Jan 15, 2008 at 09:03:19AM +0900, Katsumi Yamaoka wrote:
> >>>>> Alan Mackenzie wrote:
> > Log message:
> > * progmodes/cc-vars.el (c-constant-symbol): New function which supersedes
> > c-const-symbol. During a customize-.. call it enables an element of
> > (e.g.) c-hanging-braces alist to have its name displayed, even when the
> > default value of c-h-b etc. doesn't include the elemnt. Replace uses of
> > the old function by the new.
> By this change Emacs bootstrap fails. The `c-constant-symbol'
> function seems to have to be surrounded by `eval-and-compile'.
> Regards,
[David wrote basically the same in a separate post, to which I'm
responding here.]
Sorry about the hassle in cc-vars.el.
I'm assuming that it's the trunk (not the Emacs-22 branch) where people
have been having trouble.
<RANT>
OK, I can't reproduce this right at the moment. I haven't built Emacs
for some time, and I'm in bootstrap-hell - it keeps telling me that
such-and-such a function/variable isn't defined, and I'm going through
knocking them out one by one. On doing
% ./configure --with-gif=no --with-tiff=no
% time make bootstrap
, the latest error message I've get is:
Symbol's value as variable is void: input-decode-map
It would be really nice if this process just worked, and carried on
working (yeah I know, I'm one of the people who's broken it ;-). It
never seems to work for me, first time round, especially if I haven't
built Emacs for some time. make bootstrap _is_ supposed to work from
raw source, regardless of whatever rubbish is cluttering up the file
tree, isn't it?
</RANT>
Anyhow, back to cc-vars.el: I can reproduce the problem with:
% emacs -Q -batch -f batch-byte-compile cc-vars.el
c-constant-symbol is defun'd at cc-vars.el L77. It is used inside a
backquote expression like this: `( ..... ,(c-constant-symbol elt 20) ..).
It seems ludicrous that the byte-compiler needs an `eval-and-compile'
round the (defun c-constant-symbol ...) form. I detest cluttering up
source code. Is there any good reason for the b-c not to maintain an
obarray of its own symbols during compilation? Surely, the byte
compiler should be able to compile anything that eval-buffer can?
Anyhow, it seems the best solution for cc-vars.el right now (after all,
it's got to work with Emacs 2[01] and various flavours of XEmacs, too),
is to change c-constant-symbol into a macro.
[ 2 hours later. ] No, macros don't seem to be recorded in the symbol
table during byte compilation either. Doubleplus Ungood. So it looks
like it'll have to be eval-and-compile after all. YUCK!!!
I've committed this fix in the trunk. I'll do the same in the Emacs-22
branch later.
Cheers!
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bootstrap fails AND how about fixing the byte-compiler?
2008-01-16 0:13 ` bootstrap fails AND how about fixing the byte-compiler? Alan Mackenzie
@ 2008-01-16 0:58 ` Miles Bader
2008-01-16 2:15 ` Katsumi Yamaoka
2008-01-16 5:47 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Dan Nicolaescu
2 siblings, 0 replies; 12+ messages in thread
From: Miles Bader @ 2008-01-16 0:58 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: David Reitter, Katsumi Yamaoka, emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> make bootstrap _is_ supposed to work from raw source, regardless of
> whatever rubbish is cluttering up the file tree, isn't it?
Yeah... even recently it still pretty much seems to do that though
(last time for me was a week or two ago).
One issue I 've noticed, though: somebody changed the lisp Makefile to
rebuild autoloads before everything else, even when bootstrapping, if
there is an existing (pre-bootstrap) emacs executable in src/emacs.
This often doesn't work correctly (it barfs building the autoloads), so
you might have to do "rm src/emacs" before doing make bootstrap.
-Miles
--
Come now, if we were really planning to harm you, would we be waiting here,
beside the path, in the very darkest part of the forest?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: bootstrap fails AND how about fixing the byte-compiler?
2008-01-16 0:13 ` bootstrap fails AND how about fixing the byte-compiler? Alan Mackenzie
2008-01-16 0:58 ` Miles Bader
@ 2008-01-16 2:15 ` Katsumi Yamaoka
2008-01-16 5:47 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Dan Nicolaescu
2 siblings, 0 replies; 12+ messages in thread
From: Katsumi Yamaoka @ 2008-01-16 2:15 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: David Reitter, emacs-devel
>>>>> Alan Mackenzie wrote:
> So it looks like it'll have to be eval-and-compile after all. YUCK!!!
> I've committed this fix in the trunk. I'll do the same in the Emacs-22
> branch later.
Thanks. I've already confirmed yesterday (in Japan) that the fix
did the trick in both the trunk and the EMACS_22_BASE branch.
Regards,
^ permalink raw reply [flat|nested] 12+ messages in thread
* supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?)
2008-01-16 0:13 ` bootstrap fails AND how about fixing the byte-compiler? Alan Mackenzie
2008-01-16 0:58 ` Miles Bader
2008-01-16 2:15 ` Katsumi Yamaoka
@ 2008-01-16 5:47 ` Dan Nicolaescu
2008-01-16 8:12 ` supporting older versions of emacs Glenn Morris
2008-01-16 21:31 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Alan Mackenzie
2 siblings, 2 replies; 12+ messages in thread
From: Dan Nicolaescu @ 2008-01-16 5:47 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: David Reitter, Katsumi Yamaoka, emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> Anyhow, it seems the best solution for cc-vars.el right now (after all,
> it's got to work with Emacs 2[01] and various flavours of XEmacs, too),
> is to change c-constant-symbol into a macro.
It's obviously your choice, but is it worth it to still support
emacs-20?
21.1 was released in October 2001.
Is the number of people that do not upgrade to emacs-21, but still want
to use the latest cc-mode significant enough to be worth the trouble?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: supporting older versions of emacs
2008-01-16 5:47 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Dan Nicolaescu
@ 2008-01-16 8:12 ` Glenn Morris
2008-01-16 21:21 ` Alan Mackenzie
2008-01-16 21:31 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Alan Mackenzie
1 sibling, 1 reply; 12+ messages in thread
From: Glenn Morris @ 2008-01-16 8:12 UTC (permalink / raw)
To: Dan Nicolaescu
Cc: Alan Mackenzie, Katsumi Yamaoka, emacs-devel, David Reitter
Dan Nicolaescu wrote:
> It's obviously your choice, but is it worth it to still support emacs-20?
rms has previously said (off-list) on this subject:
"Please let's not clutter our sources with support for such old versions."
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: supporting older versions of emacs
2008-01-16 8:12 ` supporting older versions of emacs Glenn Morris
@ 2008-01-16 21:21 ` Alan Mackenzie
2008-01-16 22:29 ` Reiner Steib
0 siblings, 1 reply; 12+ messages in thread
From: Alan Mackenzie @ 2008-01-16 21:21 UTC (permalink / raw)
To: Glenn Morris; +Cc: David Reitter, Katsumi Yamaoka, Dan Nicolaescu, emacs-devel
Hi, Glenn,
On Wed, Jan 16, 2008 at 03:12:28AM -0500, Glenn Morris wrote:
> Dan Nicolaescu wrote:
> > It's obviously your choice, but is it worth it to still support
> > emacs-20?
> rms has previously said (off-list) on this subject:
> "Please let's not clutter our sources with support for such old
> versions."
Well, CC Mode contains very little such clutter - most of what is there
is there for compatibility with XEmacs.
--
Alan.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?)
2008-01-16 5:47 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Dan Nicolaescu
2008-01-16 8:12 ` supporting older versions of emacs Glenn Morris
@ 2008-01-16 21:31 ` Alan Mackenzie
2008-01-16 23:40 ` Dan Nicolaescu
1 sibling, 1 reply; 12+ messages in thread
From: Alan Mackenzie @ 2008-01-16 21:31 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: emacs-devel
Hi, Dan!
On Tue, Jan 15, 2008 at 09:47:30PM -0800, Dan Nicolaescu wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > Anyhow, it seems the best solution for cc-vars.el right now (after
> > all, it's got to work with Emacs 2[01] and various flavours of
> > XEmacs, too), is to change c-constant-symbol into a macro.
> It's obviously your choice, but is it worth it to still support
> emacs-20?
Yes, I think so, given how little effort that actually takes.
> 21.1 was released in October 2001.
> Is the number of people that do not upgrade to emacs-21, but still want
> to use the latest cc-mode significant enough to be worth the trouble?
Upgrading an unfamiliar piece of software is a nightmare of fear,
uncertainty and doubt. (And Emacs is "unfamiliar" to nearly all its
users in this context.) Will the new version of the software work? More
to the point how much work will it take to get it to work, iron out the
niggly little differences, and so on?
I think there will be a lot of Emacs users still on old versions, though
they make very little noise. I don't think giving them compatibility
headaches is the best way of persuading them to upgrade.
However, this is just my personal opinion. ;-)
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: supporting older versions of emacs
2008-01-16 21:21 ` Alan Mackenzie
@ 2008-01-16 22:29 ` Reiner Steib
2008-01-16 22:58 ` Glenn Morris
0 siblings, 1 reply; 12+ messages in thread
From: Reiner Steib @ 2008-01-16 22:29 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
On Wed, Jan 16 2008, Alan Mackenzie wrote:
> On Wed, Jan 16, 2008 at 03:12:28AM -0500, Glenn Morris wrote:
>> Dan Nicolaescu wrote:
>
>> > It's obviously your choice, but is it worth it to still support
>> > emacs-20?
>
>> rms has previously said (off-list) on this subject:
>
>> "Please let's not clutter our sources with support for such old
>> versions."
>
> Well, CC Mode contains very little such clutter - most of what is there
> is there for compatibility with XEmacs.
In Gnus, we don't support Emacs 20 any longer. Occasionally removing
compatibility code can't be done because XEmacs 21.4 needs it, too.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: supporting older versions of emacs
2008-01-16 22:29 ` Reiner Steib
@ 2008-01-16 22:58 ` Glenn Morris
2008-01-16 23:41 ` Reiner Steib
0 siblings, 1 reply; 12+ messages in thread
From: Glenn Morris @ 2008-01-16 22:58 UTC (permalink / raw)
To: emacs-devel
Reiner Steib wrote:
> In Gnus, we don't support Emacs 20 any longer. Occasionally removing
> compatibility code can't be done because XEmacs 21.4 needs it, too.
Out of interest, do you have any statistics for the fraction of people
using Emacs 21 together with bleeding-edge Gnus (eg from User-Agent
stats in the Gnus mailing lists, or somesuch)?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?)
2008-01-16 21:31 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Alan Mackenzie
@ 2008-01-16 23:40 ` Dan Nicolaescu
0 siblings, 0 replies; 12+ messages in thread
From: Dan Nicolaescu @ 2008-01-16 23:40 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: emacs-devel
Hi Alan,
Alan Mackenzie <acm@muc.de> writes:
> > 21.1 was released in October 2001.
> > Is the number of people that do not upgrade to emacs-21, but still want
> > to use the latest cc-mode significant enough to be worth the trouble?
>
> Upgrading an unfamiliar piece of software is a nightmare of fear,
> uncertainty and doubt. (And Emacs is "unfamiliar" to nearly all its
> users in this context.) Will the new version of the software work? More
> to the point how much work will it take to get it to work, iron out the
> niggly little differences, and so on?
The same argument applies to installing a new version of cc-mode too,
doesn't it?
> I think there will be a lot of Emacs users still on old versions, though
> they make very little noise. I don't think giving them compatibility
> headaches is the best way of persuading them to upgrade.
>
> However, this is just my personal opinion. ;-)
Well, you are the maintainer, so your opinion matters.
> > It's obviously your choice, but is it worth it to still support
> > emacs-20?
>
> Yes, I think so, given how little effort that actually takes.
If nothing changes, not much effort is required.
If only more recent versions of emacs/XEmacs are supported, then a lot
of cruft can go away. A cursory look over the code say that
cc-bytecomp-defvar, cc-bytecomp-fboundp and maybe cc-bytecomp-defun can
probably go.
Compare the bytecode for this:
(defmacro c-put-overlay (from to property value)
;; Put an overlay/extent covering the given range in the current
;; buffer. It's currently undefined whether it's front/end sticky
;; or not. The overlay/extent object is returned.
(if (cc-bytecomp-fboundp 'make-overlay)
;; Emacs.
`(let ((ol (make-overlay ,from ,to)))
(overlay-put ol ,property ,value)
ol)
;; XEmacs.
`(let ((ext (make-extent ,from ,to)))
(set-extent-property ext ,property ,value)
ext)))
With this:
(defmacro c-put-overlay (from to property value)
;; Put an overlay/extent covering the given range in the current
;; buffer. It's currently undefined whether it's front/end sticky
;; or not. The overlay/extent object is returned.
(if (featurep 'emacs)
;; Emacs.
`(let ((ol (make-overlay ,from ,to)))
(overlay-put ol ,property ,value)
ol)
;; XEmacs.
`(let ((ext (make-extent ,from ,to)))
(set-extent-property ext ,property ,value)
ext)))
Not sure if this would make a difference from the performance point of
view (it might for c-point for example), but reducing the amount of
cc-elisp in favor of elisp seems like a good idea.
Just my 2 cents.
--dan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: supporting older versions of emacs
2008-01-16 22:58 ` Glenn Morris
@ 2008-01-16 23:41 ` Reiner Steib
0 siblings, 0 replies; 12+ messages in thread
From: Reiner Steib @ 2008-01-16 23:41 UTC (permalink / raw)
To: emacs-devel
On Wed, Jan 16 2008, Glenn Morris wrote:
> Reiner Steib wrote:
>> In Gnus, we don't support Emacs 20 any longer. Occasionally removing
>> compatibility code can't be done because XEmacs 21.4 needs it, too.
>
> Out of interest, do you have any statistics for the fraction of people
> using Emacs 21
Even if we drop support for Emacs 21, the code still should be
compatible with XEmacs 21.4 (as it's the most recent stable version).
> together with bleeding-edge Gnus (eg from User-Agent stats in the
> Gnus mailing lists, or somesuch)?
I don't know the fraction, but a quick grep in my leafnode spool shows
that there _are_ such people ('User-Agent:.*No.Gnus.*[^X]Emacs/2[10]',
sorted + uniqued).
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix)
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (gnu/linux)
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
... used by 14 persons.
Note that most of the lists (gmane.*) and usenet groups in my spool
are computer related. In non-technical groups, ancient Emacs versions
are more common (though probably not combined with bleeding-edge
Gnus).
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2008-01-16 23:41 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1JEXu8-0004C3-Cy@cvs.savannah.gnu.org>
2008-01-15 0:03 ` bootstrap fails Katsumi Yamaoka
2008-01-16 0:13 ` bootstrap fails AND how about fixing the byte-compiler? Alan Mackenzie
2008-01-16 0:58 ` Miles Bader
2008-01-16 2:15 ` Katsumi Yamaoka
2008-01-16 5:47 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Dan Nicolaescu
2008-01-16 8:12 ` supporting older versions of emacs Glenn Morris
2008-01-16 21:21 ` Alan Mackenzie
2008-01-16 22:29 ` Reiner Steib
2008-01-16 22:58 ` Glenn Morris
2008-01-16 23:41 ` Reiner Steib
2008-01-16 21:31 ` supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?) Alan Mackenzie
2008-01-16 23:40 ` Dan Nicolaescu
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.