current CVS bootstrap broken?

current CVS bootstrap broken?

[Sam Steingold]

Hi,
I cannot bootstrap Emacs on either rh9 or w2k.
I get

make - --unix -C ../leim all
[Please ignore a syntax error on the next line - it is intentional]
Syntax error: Unterminated quoted string
make[1]: Entering directory `/cygdrive/d/gnu/emacs-mingw/leim'
"./../src/oo-spd/i386/emacs.exe" -batch --no-init-file --no-site-file --multibyte -l /cygdrive/d/gnu/emacs-mingw/leim/../lisp/international/titdic-cnv \
    --eval '(batch-titdic-convert t)' \
    -dir quail ./CXTERM-DIC
Cannot open load file: encoded-kb
Signal 127

and

$ ../src/oo-spd/i386/emacs.exe
Symbol's value as variable is void: ccl-encode-unicode-font

with "make bootstrap" on both mingw and msvc on w2k and rh9.

[this is _after_ I added (load "emacs-lisp/derived") to loadup because
it was complaining on autoloading define-derived-mode during loadup]

please help!


-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Ernqvat guvf ivbyngrf QZPN.

Re: current CVS bootstrap broken?

[Jason Rumney]

Sam Steingold wrote:

> [this is _after_ I added (load "emacs-lisp/derived") to loadup because
> it was complaining on autoloading define-derived-mode during loadup]

I noticed quite a few non-interactive functions and defvars have had 
autoload cookies added lately. I can see the point of autoload cookies 
for interactive functions, and maybe some defcustoms, but I am not sure 
of the value of bloating loaddefs.el by autoloading non-interactive 
functions. I had some problems with bootstrapping and parse-time-string 
last night, which I didn't have time to debug fully, but I think it 
might be caused by the removal of a require for parse-time and addition 
of an autoload cookie instead.

Re: current CVS bootstrap broken?

[Sam Steingold]

> * Jason Rumney <wnfbae@tah.bet> [2003-09-30 18:03:26 +0100]:
>
> Sam Steingold wrote:
> 
> > [this is _after_ I added (load "emacs-lisp/derived") to loadup because
> > it was complaining on autoloading define-derived-mode during loadup]
> 
> I noticed quite a few non-interactive functions and defvars have had
> autoload cookies added lately. I can see the point of autoload cookies
> for interactive functions, and maybe some defcustoms, but I am not
> sure of the value of bloating loaddefs.el by autoloading
> non-interactive functions. I had some problems with bootstrapping and
> parse-time-string last night, which I didn't have time to debug fully,
> but I think it might be caused by the removal of a require for
> parse-time and addition of an autoload cookie instead.

I had problems with parse-time too.

what about this:

Loading loadup.el (source)...
Using load-path (../lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version.el (source)...
Loading widget...
Loading custom...
Loading emacs-lisp/map-ynp...
Loading env...
Loading cus-start...
Note, built-in variable `x-use-underline-position-properties' not bound
Loading international/mule...
Loading international/mule-conf.el (source)...
Loading format...
Loading bindings...
Loading files...
Wrong type argument: stringp, 0
NMAKE : fatal error U1077: '"d:\gnu\emacs\src/obj-spd/i386/temacs.exe"' : return code '0xffffffff'
Stop.
NMAKE : fatal error U1077: '"c:\Program Files\Microsoft Visual Studio\VC98\BIN\nmake.exe"' : return code '0x2'
Stop.

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
If abortion is murder, then oral sex is cannibalism.

Re: current CVS bootstrap broken?

[Richard Stallman]

    I noticed quite a few non-interactive functions and defvars have had 
    autoload cookies added lately. I can see the point of autoload cookies 
    for interactive functions, and maybe some defcustoms, but I am not sure 
    of the value of bloating loaddefs.el by autoloading non-interactive 
    functions.

We make non-interactive functions autoloadable to make it easy to call
them.  We make variables preloaded so that programs can set them more
easily.

     I had some problems with bootstrapping and parse-time-string 
    last night, which I didn't have time to debug fully, but I think it 
    might be caused by the removal of a require for parse-time and addition 
    of an autoload cookie instead.

If that is the case, I suspect that the code is setting some variable
in the file parse-time.

Re: current CVS bootstrap broken?

[Jason Rumney]

Richard Stallman wrote:

>      I had some problems with bootstrapping and parse-time-string 
>     last night, which I didn't have time to debug fully, but I think it 
>     might be caused by the removal of a require for parse-time and addition 
>     of an autoload cookie instead.
> 
> If that is the case, I suspect that the code is setting some variable
> in the file parse-time.

It appears to be a chicken and egg problem. Maybe it can be solved by a 
change to loaddefs-boot.el?

The code is in vc-cvs.el, and is a call to parse-time-string which is 
now autoloaded. The problem encountered is that when Emacs tries to save 
loaddefs.el after generating it, it loads vc-cvs.el and tries to run the 
code in question. But since loaddefs.el has not been written yet, the 
autoload does not work, and parse-time-string is left undefined.

Re: current CVS bootstrap broken?

[Andre Spiegel]

On Wed, 2003-10-01 at 17:09, Jason Rumney wrote:

> The code is in vc-cvs.el, and is a call to parse-time-string which is 
> now autoloaded. The problem encountered is that when Emacs tries to save 
> loaddefs.el after generating it, it loads vc-cvs.el and tries to run the 
> code in question. But since loaddefs.el has not been written yet, the 
> autoload does not work, and parse-time-string is left undefined.

It is strange that VC should try to run vc-cvs-parse-entry when
loaddefs.el is saved, as you say.  That should only happen if
loaddefs.el was under CVS control, which it isn't.  Wasn't it taken out
of CVS just recently?  Could it be that some people still have it in
their CVS/Entries?

Does it really happen as you say?  Can you provide a stack trace?

Re: current CVS bootstrap broken?

[Jason Rumney]

Andre Spiegel <spiegel@gnu.org> writes:

> It is strange that VC should try to run vc-cvs-parse-entry when
> loaddefs.el is saved, as you say.  That should only happen if
> loaddefs.el was under CVS control, which it isn't.  Wasn't it taken out
> of CVS just recently?  Could it be that some people still have it in
> their CVS/Entries?

/loaddefs.el/2.95/Sat Aug  9 10:21:06 2003/-kb/

Could this be a CVS bug then?

Re: current CVS bootstrap broken?

[Miles Bader]

Jason Rumney <jasonr@gnu.org> writes:
> > Wasn't it taken out of CVS just recently?  Could it be that some
> > people still have it in their CVS/Entries?
> 
> /loaddefs.el/2.95/Sat Aug  9 10:21:06 2003/-kb/
> 
> Could this be a CVS bug then?

Here's what I have:

   $ grep loaddefs lisp/CVS/Entries
   /loaddefs-boot.el/1.1/Mon Sep 15 05:36:56 2003//

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: current CVS bootstrap broken?

[Andre Spiegel]

On Thu, 2003-10-02 at 09:52, Jason Rumney wrote:

> /loaddefs.el/2.95/Sat Aug  9 10:21:06 2003/-kb/
> 
> Could this be a CVS bug then?

Since others don't seem to have that problem (neither do I), it could be
due to the way you update from the repository.  As far as I recall, any
"cvs update" on the lisp directory ought to remove the stale entry, but
"cvs update -d -P" should definitely do it.  Can you try that?

I just checked the cvs status of loaddefs.el, and it was indeed removed
at version 2.96 and placed into lisp/Attic on savannah.

Re: current CVS bootstrap broken?

[Andreas Schwab]

Jason Rumney <jasonr@gnu.org> writes:

> Andre Spiegel <spiegel@gnu.org> writes:
>
>> It is strange that VC should try to run vc-cvs-parse-entry when
>> loaddefs.el is saved, as you say.  That should only happen if
>> loaddefs.el was under CVS control, which it isn't.  Wasn't it taken out
>> of CVS just recently?  Could it be that some people still have it in
>> their CVS/Entries?
>
> /loaddefs.el/2.95/Sat Aug  9 10:21:06 2003/-kb/
>
> Could this be a CVS bug then?

Is this file locally modified?  Then you should run "cvs up -C loaddefs.el".
CVS won't remove a file that is locally modified unless you told it to
discard the changes.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: current CVS bootstrap broken?

[Andreas Schwab]

Jason Rumney <jasonr@gnu.org> writes:

> Richard Stallman wrote:
>
>>      I had some problems with bootstrapping and parse-time-string
>> last night, which I didn't have time to debug fully, but I think it
>> might be caused by the removal of a require for parse-time and addition
>> of an autoload cookie instead.
>> If that is the case, I suspect that the code is setting some variable
>> in the file parse-time.
>
> It appears to be a chicken and egg problem. Maybe it can be solved by a
> change to loaddefs-boot.el?

Yes, I think this file needs to be regenerated from time to time.  Please
try again now.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: current CVS bootstrap broken?

[Jason Rumney]

Andreas Schwab wrote:

 >> Maybe it can be solved by a change to loaddefs-boot.el?
> 
> 
> Yes, I think this file needs to be regenerated from time to time.  Please
> try again now.

It works now, even with loaddefs.el in CVS/Entries. The reason
loaddefs.el hasn't gone from my working copy is that I had added
it to .cvsignore.