On 30 May 2002, stephen(a)xemacs.org wrote:
>>>>> "Andy" == Andy Piper
<andy(a)xemacs.org> writes:
Andy> Maybe Mike Sperber could comment on this. I've never
Andy> understood why the compile time paths get put into the
Andy> executable.
Because those are the libraries that are loaded, of course. The
intent was to make it easy for maintainers and hackers to find the
libraries that need to be changed to fix bugs or enhance XEmacs. For
them, load-history is the right place to look. If you don't have
access to them, well, you don't have access to them.
As it is, "It took me forever to find the damn library because
find-library was looking for it in the wrong place, and now that I've
found and fixed it XEmacs forgets all my changes when I restart" is a
FAQ. If people would only build from source and run-in-place this
wouldn't be a problem. ;-)
One sensible way to handle this is to add a SEARCH-LOAD-PATH-TOO flag
to `find-library' and `locate-library', if it's nil have them warn
"library source not found, probably dumped into XEmacs? use prefix
arg to search path" on not found, and if non-nil search for the
library on the path. I would prefer those semantics (rather than
defaulting to searching load-path) to reduce the incidence of the FAQ,
but maybe I'm just a worry-wart.
I think you're missing something here with the search load path thing.
load-history is used to figure out what file contains the function.
The load-path is used to find the file (except when absolute file
names are used).
The find-function-at-point (etc) functions use load-history to figure
out where a function comes from.
load-history constains stuff like the following:
(...
("font-lock" (require . fontl-hooks) font-lock-verbose
font-lock-message-threshold ...)
...
("/opt/sfw/lib/xemacs-21.4.6/lisp/specifier.elc" make-specifier-and-init
...)
...
)
If you do find of 'font-lock-verbose', we look in load-history for it,
and we find that the definition is in "font-lock". We use the
**load-path*** to find where "font-lock" is. (Note also that there is
built in 'fragility' here by using load-path, because there is no
guarantee that I haven't added shadow files to load-path)
On the other hand, if you try to find 'make-specifier-and-init', we
look in load-history, and find that it is defined in
"/opt/sfw/lib/xemacs-21.4.6/lisp/specifier.elc" So, we know exactly
where this source file is - it is
"/opt/sfw/lib/xemacs-21.4.6/lisp/specifier.el"
This works as long as the file is there.
When I do this on windows, I find that 'make-specifier-and-init' is
defined in "f:\\xemacs\\xemacs-21.4-release\\lisp\\specifier.elc".
This file does not exist on my windows machine so the find operation fails.
So, something needs to be fixed. Perhaps it would be better to change
absolute paths (that do not exist) in load-history to load-path
relative names - eg change "/opt/sfw/lib/xemacs-21.4.6/lisp/specifier.elc"
to "specifier". Alternatively, we could make 'symbol-file' smarter
by not returning absolute paths that don't exist, or make
'find-function-search-for-symbol' try harder.
-jeff