bootstrap fails

bootstrap fails

[Katsumi Yamaoka]

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

Re: bootstrap fails AND how about fixing the byte-compiler?

[Alan Mackenzie]

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

Re: bootstrap fails AND how about fixing the byte-compiler?

[Miles Bader]

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?

Re: bootstrap fails AND how about fixing the byte-compiler?

[Katsumi Yamaoka]

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

supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?)

[Dan Nicolaescu]

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?

Re: supporting older versions of emacs

[Glenn Morris]

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

Re: supporting older versions of emacs

[Alan Mackenzie]

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.

Re: supporting older versions of emacs

[Reiner Steib]

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/

Re: supporting older versions of emacs

[Glenn Morris]

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

Re: supporting older versions of emacs

[Reiner Steib]

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/

Re: supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?)

[Alan Mackenzie]

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

Re: supporting older versions of emacs (was: Re: bootstrap fails AND how about fixing the byte-compiler?)

[Dan Nicolaescu]

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