3:59 p.m.
I'm moving this to xemacs-beta since I can't read xemacs-review and
there are a couple of issues here I'd like to discuss.
On 12 Dec 2000 at 13:38:22 +0900, Yoshiki Hayashi <yoshiki(a)xemacs.org>
wrote:
james(a)eecs.ukans.edu (Jerry James) writes:
> There are only 3 calls to paths-find-architecture-directory, including
> the one that sets a module-related path. This change does not affect
> the other 2 calls, and makes all of the module path variables get good
> values.
>
> 2000-11-29 Jerry James <james(a)eecs.ukans.edu>
>
> * find-paths.el (paths-find-architecture-directory): Check for
> directory base in directory system-configuration instead of
> checking for a directory with the concatenated name.
Sorry, I have to veto this patch.
module-load-path values are (Note these are build in
different directory):
Installed XEmacs before patched:
("/opt/local/lib/xemacs/site-modules/"
"/src/xemacs/modules/" "/src/xemacs/modules/alloc-test/"
"/src/xemacs/modules/base64/" "/src/xemacs/modules/ldap/"
"/src/xemacs/modules/sample/" "/src/xemacs/modules/wnn/"
"/src/xemacs/modules/zlib/")
I don't understand this. I also am building in a different directory,
but my module-load-path is nil at startup. I submitted the patch based
on 21.2.37, but I just tried again with 21.2.38 and got the same
result. Why do you have directories in your module-load-path but I
don't?
Note that all but the first one are wrong, anyway, since the installed
XEmacs shouldn't be pointing into the source tree.
Installed XEmacs after patched:
("/opt/local/lib/xemacs/site-modules/"
"/opt/local/lib/xemacs-21.2-b37/i686-pc-linux/"
"/opt/local/lib/xemacs-21.2-b37/i686-pc-linux/include/"
"/opt/local/lib/xemacs-21.2-b37/i686-pc-linux/modules/")
Yes, the second and third directories are bogus, but the first and
fourth are right. I have a slightly revised patch that fixes this.
Run-in-place XEmacs before patched (build inside source directory):
("/opt/local/lib/xemacs/site-modules/"
"/work/yoshiki/orig/xemacs/modules/"
"/work/yoshiki/orig/xemacs/modules/base64/"
"/work/yoshiki/orig/xemacs/modules/ldap/"
"/work/yoshiki/orig/xemacs/modules/sample/"
"/work/yoshiki/orig/xemacs/modules/zlib/")
Again, my XEmacs has module-load-path as nil in this case. I don't
understand why you are picking up values there but I'm not.
Run-in-place XEmacs after patched (build outside source directory):
("/opt/local/lib/xemacs/site-modules/"
"/opt/local/lib/xemacs-21.2-b37/i686-pc-linux/"
"/opt/local/lib/xemacs-21.2-b37/i686-pc-linux/include/"
"/opt/local/lib/xemacs-21.2-b37/i686-pc-linux/modules/")
Run-in-place XEmacs after patched (build inside source directory):
("/opt/local/lib/xemacs/site-modules/"
"/src/xemacs/modules/" "/src/xemacs/modules/alloc-test/"
"/src/xemacs/modules/base64/" "/src/xemacs/modules/ldap/"
"/src/xemacs/modules/sample/" "/src/xemacs/modules/wnn/"
"/src/xemacs/modules/zlib/")
When I apply your patch and install XEmacs, XEmacs has these
two wrong directories in module-load-path.
"/opt/local/lib/xemacs-21.2-b37/i686-pc-linux/"
"/opt/local/lib/xemacs-21.2-b37/i686-pc-linux/include/"
Other examples show that there might be something you have
missed. It would be really great if you can provide a patch
that solves all these problems.
First I need to understand why you are getting different results than I
am. FWIW, the following patch (against vanilla XEmacs 21.2.38 sources,
ignoring my previous patch) cleared up the two bogus directories for me:
--- lisp/find-paths.el.ORIG Wed Sep 13 10:57:43 2000
+++ lisp/find-paths.el Tue Dec 19 23:11:02 2000
＠＠ -235,14 +235,15 ＠＠
(or
;; from more to less specific
(paths-find-version-directory roots
- (concat base system-configuration)
+ (paths-construct-path
+ (list system-configuration base))
envvar default)
(paths-find-version-directory roots
base
- envvar)
+ envvar default)
(paths-find-version-directory roots
system-configuration
- envvar)))
+ envvar default)))
(defun construct-emacs-version-name ()
"Construct the raw XEmacs version number."
--
Jerry James
5:29 p.m.
New subject: Find architecture-specific directories correctly
Review deleted, reviewers should be reading xemacs-beta.
>>>> "Jerry" == Jerry James
<james(a)eecs.ukans.edu> writes:
Jerry> I don't understand this. I also am building in a different
Jerry> directory, but my module-load-path is nil at startup. I
Jerry> submitted the patch based on 21.2.37, but I just tried
Jerry> again with 21.2.38 and got the same result. Why do you
Jerry> have directories in your module-load-path but I don't?
I haven't tested with an installed xemacs, but:
Run-in-place XEmacs before patched (build inside source directory):
("/opt/local/lib/xemacs/site-modules/"
"/work/yoshiki/orig/xemacs/modules/"
"/work/yoshiki/orig/xemacs/modules/base64/"
"/work/yoshiki/orig/xemacs/modules/ldap/"
"/work/yoshiki/orig/xemacs/modules/sample/"
"/work/yoshiki/orig/xemacs/modules/zlib/")
Jerry> Again, my XEmacs has module-load-path as nil in this case.
Jerry> I don't understand why you are picking up values there but
Jerry> I'm not.
FWIW, I get what yoshiki does in the pre-patch cases. Here's my
./configure:
./configure '--with-widgets=athena' '--with-athena=3d'
'--with-dialogs=athena' '--with-sound=none,nas' '--with-mule'
'--with-xim=xlib' '--with-xfs' '--use-union-type'
'--pdump'
With run-in-place built _outside_ of the source directory, I get only
the site-modules directory.
If I build _outside_ of the source directory, but _with_ a symlink in
the build directory to the modules directory in the source, I get the
same behavior as a building in the source directory.
If I then rm the symlink, it still finds the (now non-existent)
sibling modules hierarchy. This sound like pdump lossage to me;
finding directories that aren't there clearly indicates that they're
dumped into the binary somehow.
Lessee ... well, it's dumping lossage, but probably not pdump
lossage. Rebuilding without --pdump gives the same results. In fact,
I can move the dumped xemacs to /tmp and start it from there, and it
still remembers the (now non-existent) module-load-path.
load-path seems to be properly initialized to nil in the dumped
xemacs; running from /tmp/xemacs finds only the installed package
hierarchy, but no other lisp (since I haven't installed this version
of XEmacs yet).
BTW, --debug-paths doesn't give any information about modules. It
would be nice to fix that. (It might help you get a handle on why the
modules pathfinding is weird, too. On second thought, maybe not; all
the debug-paths stuff is in startup.el, so it probably doesn't have
any bearing on the current weirdness. Funnily enough, dump-paths.el
does seem to have treatment of debug-paths right.)
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
4:20 p.m.
New subject: Find architecture-specific directories correctly
Question: why are we setting module-load-path at _dump_ time? (See
dump-paths.el and loadup.el.) The whole point of modules is that
they're loaded at runtime. So dumping the contents of a module seems
at best redundant, but more like downright hazardous to me.
>>>> "Jerry" == Jerry James
<james(a)eecs.ukans.edu> writes:
Jerry> I don't understand this. I also am building in a different
Jerry> directory, but my module-load-path is nil at startup. I
Jerry> submitted the patch based on 21.2.37, but I just tried
Jerry> again with 21.2.38 and got the same result. Why do you
Jerry> have directories in your module-load-path but I don't?
I don't understand why you don't have anything in your
module-load-path, but what's in mine (and Yoshiki's) I believe is
coming because there is no startup code in current CVS to set
module-load-path; it's only done at dump time AFAICT. I wonder if
maybe Yoshiki's got a modules -> $srcdir/modules symlink in the build
directory?
Maybe you fixed this already and forgot to diff this file?
This path duplicates the module-load-path initialization from
dump-paths (which is run early at dump-time only AFAICT), to
startup.el (which is run later both at dump-time and at run-time).
Not tested, I'm working across a slow modem, and it's bedtime. Will
test tomorrow, but I thought I'd let you know what I found.
Index: lisp/startup.el
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/startup.el,v
retrieving revision 1.24.2.24
diff -u -r1.24.2.24 startup.el
--- startup.el 2000/11/29 08:27:21 1.24.2.24
+++ startup.el 2000/12/21 16:07:24
＠＠ -1174,6 +1174,7 ＠＠
;; don't let /tmp_mnt/... get into the load-path or exec-path.
(abbreviate-file-name invocation-directory)))
+;; #### Part of this code is duplicated in dump-paths.el at top-level.
(defun startup-setup-paths (roots user-init-directory
&optional
inhibit-early-packages inhibit-site-lisp
＠＠ -1231,6 +1232,21 ＠＠
last-package-load-path
lisp-directory
site-directory))
+
+ (setq module-directory (paths-find-module-directory roots))
+ (if debug-paths
+ (princ (format "module-directory:\n%S\n" module-directory)
+ 'external-debugging-output))
+ (setq site-module-directory (and (null inhibit-site-modules)
+ (paths-find-site-module-directory roots)))
+ (if (and debug-paths (null inhibit-site-modules))
+ (princ (format "site-module-directory:\n%S\n" site-module-directory)
+ 'external-debugging-output))
+
+ (setq module-load-path
+ (paths-construct-module-load-path roots
+ module-directory
+ site-module-directory))
(setq Info-directory-list
(paths-construct-info-path roots
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
5:28 a.m.
New subject: Find architecture-specific directories correctly
>>>> "me" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
me> Question: why are we setting module-load-path at _dump_ time?
I still wanna know. I'd rip it out and test it, but I don't use any
modules so I don't think that test would have any meaning. This is
really a design decision at this stage of the game.
AFAICT, what ripping that out means is that you cannot _load_ a module
within the dump process, although you can _dump_ code that will load
modules once the top level loop gets started (since that's after
startup.el does it's thing).
me> This path[sic] duplicates the module-load-path initialization
me> from dump-paths (which is run early at dump-time only AFAICT),
me> to startup.el (which is run later both at dump-time and at
me> run-time). Not tested, I'm working across a slow modem, and
me> it's bedtime. Will test tomorrow, but I thought I'd let you
me> know what I found.
me> Index: lisp/startup.el
me> ===================================================================
me> RCS file: /usr/CVSroot/XEmacs/xemacs/lisp/startup.el,v
etc etc. OK, I've tested it pretty thoroughly.
That patch gives consistent behavior, installed or run-in-place,
build-in-source or with --srcdir, and in the case of --srcdir, whether
or not there is an existing build or just pristine source in $srcdir.
But:
With this patch, and Jerry's improved Dec. 20 patch, it does _not_
detect the run-in-place sibling modules directory. This seems to be
incorrect behavior to me. (I don't know how to fix it offhand.)
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
8736
days inactive
8738
days old
3 comments
2 participants
participants (2)
-
Jerry James -
Stephen J. Turnbull