Re: EMACSLOADPATH in lisp/Makefile.in

[Ken Raeburn]

I've been unable to keep up on Emacs mail for a while, so I've just
seen this.  I apologize for not responding promptly.  (If you put my
address on the recipient line, my gnus mail filing will put it in a
group I check more often.)

Eli Zaretskii <address@hidden> writes:
> This change in lisp/:
> 
>   2000-11-02  Ken Raeburn  <address@hidden>
> 
>       * Makefile.in (emacs): Set EMACSLOADPATH always.
> 
> breaks "make recompile" when $srcdir is ".", because it forces 
> EMACSLOADPATH in several rules which previously didn't do that.
> 
> The following changes fix this for me.  Okay to commit?
> 
> 2000-11-13  Eli Zaretskii  <address@hidden>
> 
>       * Makefile.in (custom-deps, finder-data, autoloads, recompile):
>       Don't set EMACSLOADPATH.

My patch was put in to deal with EMACSLOADPATH not being set to
anything useful when doing "make bootstrap" with CANNOT_DUMP set.  The
load path defaults to the directory where the lisp files haven't been
installed yet, and loadup.el can't be found.

Now, if we have to make a choice between "make bootstrap" with
CANNOT_DUMP and "make recompile", certainly the latter is preferable,
but I'd like to try to make both work, and you don't describe what
you're doing and how things break.

If you're using a different version of Emacs to do the compilation, I
can see how my patch would make things more difficult.  But changing
how the load path is set so that you'd override that at the same time
would fix that.  And I can also see other ways that using an installed
Emacs could break things anyways -- e.g., if preloaded macro
definitions have changed since the installed Emacs -- so using the
newly built Emacs seems to me like it'd be preferable whenever it's
possible.

As for using the Emacs from the src directory, I just ran a "make
recompile" with the load path setting in the Makefile and building in
the source tree (srcdir is not "." but a full path to the top-level
directory in the tree), and it seems to have gone fairly well
(processed 227 files, 14 directories).

I think it's an unrelated bug that batch-byte-recompile-directory
doesn't cause a non-zero exit status when one of the files doesn't
compile properly, and another that I actually got one such error (that
I know of).  Most of the files compiled just fine.

Ken