Re: Bootstrap problem.

[Lute Kamstra <Lute.Kamstra.lists@xs4all.nl>]

Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:

> Lute Kamstra <Lute.Kamstra.lists@xs4all.nl> writes:
>
>> Add a definition to lisp file A and make it available to other lisp
>> files by adding an autoload cookie.  Commit the change.  Then add
>> some code to lisp file B that depends on the presence of this
>> definition to compile.  Commit this change as well.
>>
>> As I found out the hard way, this leads to problems in two cases:
>
> [...]
>
>> 2. Someone has a CVS tree and did the last update before the change in
>>    file A.  Then that person does per next update after the change to
>>    file B and then does a make bootstrap.  bootstrap-emacs uses the
>>    old loaddefs.el that does not contain an autoload of the required
>>    definition in file A and fails to compile file B.
>>
>>    A second make bootstrap would work fine as this would use the new
>>    loaddefs.el that was created during the first make bootstrap that
>>    failed.
>
> Strange: I just looked more carefully at the bootstrap process and it
> seems that this second problem should not occur.  From what I now
> understand, bootstrap already does what I want: it first updates
> loaddefs.el and then builds bootstrap-emacs and dumps it with the
> up-to-date loaddefs.el loaded.
>
> But now I don't know how to explain Chris Moore's recent bug report on
> emacs-pretest-bug.

I figured it out: a make clean deletes the emacs executable, but not
loaddefs.el.  So a subsequent make bootstrap cannot use the old emacs
to regenerate loaddefs.el and bootstrap-emacs uses the old loaddefs.el
to compile the new lisp files.

We could let make clean delete loaddefs.el as well.  Or would that
have any negative effects that I'm not aware of?

Lute.