Re: EMACSLOADPATH in lisp/Makefile.in

[Eli Zaretskii]

On 2 Dec 2000, Ken Raeburn wrote:

> (If you put my address on the recipient line, my gnus mail filing
> will put it in a group I check more often.)

Makes you wonder whether Gnus is such a good idea after all ;-)

I usually try to spare people receiving the same message twice (some
people actually complained to me about that), so if I know that
someone is on a mailing list, I might edit their name from the
explicit addressees.  You happen to be the first one who complained
about that...

Perhaps you simply need to tinker with your Gnus filtering (e.g., a
message whose text contains your name might be more important).

> 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.
[snip]
> 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.

Perhaps in the future you could put such explanations into a comment 
within lisp/Makefile.in (ChangeLog entries are inappropriate for this).  
If it were there, perhaps I could be smarter about the fix I suggested.  
As things were, without any response from you, no objections from anyone 
else, and with Gerd's approval, I thought it was simply an oversight: you 
changed the value of $(emacs), but didn't see that $(emacs) was used in 
more than one place.

> you don't describe what you're doing and how things break.

Sorry, I thought it was obvious: with $srcdir set to ".", compiling in
a subdirectory of the lisp/ directory will fail, because EMACSLOADPATH
is set to ".".  When EMACSLOADPATH is ".", Emacs cannot find any 
require'd file unless it is in the current directory.

> If you're using a different version of Emacs to do the compilation, I
> can see how my patch would make things more difficult.

No, I used the just-built version of Emacs, like this:

    cd lisp
    make recompile EMACS=../bin/emacs

(This is the MS-DOS port, where "make install" installs the Emacs
executable in the bin/ subdirectory of the Emacs source tree.)

> 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

Try setting $srcdir to ".", not to the absolute pathname, and you will
see the problem.  The problem only happens when "make recompile"
compiles some file in some subdirectory of lisp/.

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

I have several gripes about "make recompile" as well, but I'm not sure
this is a good time to rock the boat there.

One problem that annoys me is that lisp/Makefile.in doesn't know about
dependencies between .el files (e.g., because one file require's
another), so I get lots of "Source file foo.el newer than
byte-compiled file" messages.  Makes you wonder whether this makes a
potentially broken .elc file; so I normally recompile the offending
files at least one more time.

It would be nice if "make recompile" at least compiled some crucial
files, like those in COMPILE_FIRST, and maybe some more, before all
the rest.