[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EMACSLOADPATH in lisp/Makefile.in
Re: EMACSLOADPATH in lisp/Makefile.in
Sun, 3 Dec 2000 13:17:35 +0200 (IST)
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
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.
> 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:
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