Re: EMACSLOADPATH in lisp/Makefile.in

[Ken Raeburn]

Eli Zaretskii <address@hidden> writes:
> 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...

I wouldn't call it a complaint, quite, just a half-assed excuse for
not reading the mail sooner. :-)

I have Gnus configured to hide duplicate messages, so the extra copies
aren't a big deal for me, but I can understand people's annoyance.

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

That's a good idea, and would take care of this problem I've had here
and elsewhere.

Sorting my incoming mail is already slow enough, what's a few more
minutes?  I've started thinking that maybe I should implement my
mail-filing stuff in C; then I "merely" need to write the support code
to dynamically load it into whatever Emacs I'm running at the time.
Or at least grow the regex cache size considerably, or make it
run-time controllable -- the default is 20, but I have more than 160
entries in my Gnus splitting regexp list, each of which will be
applied to each message before processing the next message.  (Oh yeah,
I definitely should try a bigger cache.)  Maybe make compiled regexps
into first-class Lisp objects so Gnus can hang onto them for as long
as it needs to, and free up the storage at GC time.

Then again, maybe I should profile it first....

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

Understandable.  I'll try to be more careful.

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

Ah... interesting.  The reason it wasn't obvious was that on UNIX, the
configure script explicitly converts a relative $srcdir to be
absolute.  So the only way I can get that is to edit the Makefiles or
manually override it at build time.

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

So you're installing before running "make recompile"; okay.  I try to
do at least some of my bootstraps without installing anything first.
But yeah, that should work. :-)

> 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 just gave it a try, and bytecomp couldn't load.  I guess the subdir
processing isn't being used for a non-absolute directory or something
like that.

Using

        EMACSLOADPATH=`cd $(lisp)&&pwd`

seems to work for me, by providing an absolute pathname.  Would it
work for you?

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

That's why I always go for "make bootstrap" instead.  But one of my
machines is fast enough for that not to be too horribly inconvenient.

Ken