2:57 a.m.
Hi, Michael,
Sorry to bring this up again, I know this topic has been hashed out
multiple times, but I'm in a small fix and I could use some help. I
hope I've just missed something with respect to package configuration.
As you may know, I've recently created a Windows-native setup kit for
21.4. This setup kit can run on the user's machine and the resulting
software can be installed in a directory of the user's choosing. The
kit includes both core 21.4 (binaries and lisp) and also a default set
of packages. If I understand correctly, in order for those packages
to be found at run-time, the builder of the 21.4 kit must either: 1)
know an absolute path where the packages will be installed or 2) the
packages must be installed under the root of the XEmacs 21.4 tree.
To be more concrete, if I use the following settings in the nt/config.inc file:
INSTALL_DIR=c:\Program Files\XEmacs\XEmacs-$(XEMACS_VERSION_STRING)
PACKAGE_PREFIX=C:\Program Files\XEmacs
and build and install XEmacs 21.4, then I can run from
c:\Program Files\XEmacs\XEmacs-21.4.18\i586-pc-win32\xemacs.exe
and Bob's my uncle and all works great. But if once I make a setup
kit from that build, I (or any other user) can install to a different
hierarchy, say "c:\Program Files\XEmacs1" and the packages will not be
found when running the XEmacs binary.
As far as I understand, assuming I want the users to be able to
install to arbitrary locations, I can fix this in either of 2 ways:
1) I can install the packages underneath the 21.4.18 hierarchy or
2) I can set EMACSPACKAGEPATH (either through the registry or an
environment variable) to point to the package hierarchy.
Both of those solutions are slightly problematic from my point of
view: #1 is kind of aesthetically yucky (the packages and the core are
distinct and I don't want to install my packages underneath my core)
and besides, I'd like to be able to install multiple cores (21.4.18,
21.4.19 and 21.5.b23, for instance) in parallel directories and not
force each one to have its own package tree. #2 currently does not
seem to work identically for 21.4 and 21.5 - "xemacs-packages" gets
appended to EMACSPACKAGEPATH for 21.4 but not for 21.5. Other than
that, I suppose solution #2 works, but it would be nice not to have to
have to set the envariable; it's one more thing that can go wrong in
the user's installation.
Michael - do you have any suggestions or insights? At configuration
time, Is it possible to specify a package path _relative_ to the
installation directory? (I just tried specifying
--with-package-prefix=.. (on my Linux box) to a 21.5 configure, and
when running XEmacs, that got interpreted as relative to the current
directory at run time.) Alternatively, is there a small amount of
lisp I could generate at install time and add it to site-start.el? My
thinking is that this code could propose an alternate package root at
startup time. Or does site-start.el run too late in the init process?
Thank you for your help,
Vin
5:50 p.m.
Vin Shelton <acs(a)xemacs.org> writes:
to be found at run-time, the builder of the 21.4 kit must either: 1)
know an absolute path where the packages will be installed or 2) the
packages must be installed under the root of the XEmacs 21.4 tree.
... or you set appropriate environment variables, but I'm sure you
know that.
As far as I understand, assuming I want the users to be able to
install to arbitrary locations, I can fix this in either of 2 ways:
1) I can install the packages underneath the 21.4.18 hierarchy or
2) I can set EMACSPACKAGEPATH (either through the registry or an
environment variable) to point to the package hierarchy.
Both of those solutions are slightly problematic from my point of
view: #1 is kind of aesthetically yucky (the packages and the core are
distinct and I don't want to install my packages underneath my core)
and besides, I'd like to be able to install multiple cores (21.4.18,
21.4.19 and 21.5.b23, for instance) in parallel directories and not
force each one to have its own package tree. #2 currently does not
seem to work identically for 21.4 and 21.5 - "xemacs-packages" gets
appended to EMACSPACKAGEPATH for 21.4 but not for 21.5.
Do you mean that "xemacs-packages" *needs* to be appended ...? If so,
there's something funky here.
Other than that, I suppose solution #2 works, but it would be nice
not to have to have to set the envariable; it's one more thing that
can go wrong in the user's installation.
Michael - do you have any suggestions or insights?
I think you still should try to convince XEmacs to find the packages
at run-time, based on where the executable is. That's generally the
most robust approach. The trick is to make it recognize a "root", and
the path-searching machinery will take over from there. You should
look at `paths-emacs-root-p' and `paths-find-emacs-root' for places to
tweak---this shouldn't be hard if you're just doing Windows and don't
have to worry about Unix. (We can sort all that out later.) In
particular, `paths-find-emacs-root' should probably go up at least two
directories.
I don't know if this helps---let me know if I can do more.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
9:46 p.m.
Mike,
Thanks for replying.
On 12/19/05, Michael Sperber <sperber(a)informatik.uni-tuebingen.de> wrote:
Vin Shelton <acs(a)xemacs.org> writes:
> As far as I understand, assuming I want the users to be able to
> install to arbitrary locations, I can fix this in either of 2 ways:
> 1) I can install the packages underneath the 21.4.18 hierarchy or
> 2) I can set EMACSPACKAGEPATH (either through the registry or an
> environment variable) to point to the package hierarchy.
> Both of those solutions are slightly problematic from my point of
> view: #1 is kind of aesthetically yucky (the packages and the core are
> distinct and I don't want to install my packages underneath my core)
> and besides, I'd like to be able to install multiple cores (21.4.18,
> 21.4.19 and 21.5.b23, for instance) in parallel directories and not
> force each one to have its own package tree. #2 currently does not
> seem to work identically for 21.4 and 21.5 - "xemacs-packages" gets
> appended to EMACSPACKAGEPATH for 21.4 but not for 21.5.
Do you mean that "xemacs-packages" *needs* to be appended ...? If so,
there's something funky here.
Yes, 21.4 automatically appends "xemacs-packages" to the
EMACSPACKAGEPATH, but 21.5 does not at least under Windows. More
specifically, for two identically-configured XEmacsen, the commands
required to find the lisp code which lives in
e:\XEmacs\Packages\xemacs-packages\lisp differ:
EMACSPACKAGEPATH='e:\XEmacs\Packages\xemacs-packages'
~e/acs/test/xemacs-21.5-installed/i586-pc-win32/xemacs.exe
is required for 21.5, and
EMACSPACKAGEPATH='e:\XEmacs\Packages'
~e/acs/test/xemacs-21.4-installed/i586-pc-win32/xemacs.exe
is required for 21.4.
I think you still should try to convince XEmacs to find the packages
at run-time, based on where the executable is. That's generally the
most robust approach. The trick is to make it recognize a "root", and
the path-searching machinery will take over from there. You should
look at `paths-emacs-root-p' and `paths-find-emacs-root' for places to
tweak---this shouldn't be hard if you're just doing Windows and don't
have to worry about Unix. (We can sort all that out later.) In
particular, `paths-find-emacs-root' should probably go up at least two
directories.
I don't know if this helps---let me know if I can do more.
Here's what I've come up with. I'm not particularly happy with the
hygiene of the patch because:
1. I had to add the new defun paths-find-potential-package-root and
couldn't add that functionality into paths-find-emacs-root (maybe
that's OK)
2. in paths-find-emacs-roots I had to add another call to
paths-uniq-append and a temporary variable, combined-roots. It seems
I should have been able to just extend paths-uniq-append, but maybe
that's not a big deal, either.
Michael, if you don't mind, please help me clean this up - I'd be
grateful for any help you'd offer.
Thanks,
Vin
9:27 a.m.
Vin Shelton <acs(a)xemacs.org> writes:
Here's what I've come up with. I'm not particularly
happy with the
hygiene of the patch because:
1. I had to add the new defun paths-find-potential-package-root and
couldn't add that functionality into paths-find-emacs-root (maybe
that's OK)
2. in paths-find-emacs-roots I had to add another call to
paths-uniq-append and a temporary variable, combined-roots. It seems
I should have been able to just extend paths-uniq-append, but maybe
that's not a big deal, either.
Michael, if you don't mind, please help me clean this up - I'd be
grateful for any help you'd offer.
I can't find much fault with it, except for the code and work
duplication in between `paths-find-emacs-root' and your
`paths-find-potential-package-root'. My suggestion would be to rename
`paths-find-emacs-root' to `paths-find-invocation-roots' and have it
return a list instead of a single string. Approximately like so
(untested):
(defun paths-find-emacs-root (invocation-directory invocation-name)
"Find the run-time root of XEmacs.
INVOCATION-DIRECTORY is a directory containing the XEmacs executable.
INVOCATION-NAME is the name of the executable itself."
(let* ((executable-file-name (paths-chase-symlink
(concat invocation-directory
invocation-name)))
(executable-directory (file-name-directory executable-file-name))
(maybe-root-1 (file-name-as-directory
(paths-construct-path '("..") executable-directory)))
(maybe-root-2 (file-name-as-directory
(paths-construct-path '(".." "..") executable-directory)))
(maybe-root-3 (file-name-as-directory
(paths-construct-path '(".." "..") executable-directory)))
(maybe-root-4 (file-name-as-directory
(paths-construct-path '(".." ".." "..")
executable-directory))))
(paths-filter #'paths-emacs-root-p
(list maybe-root-1 maybe-root-2 maybe-root-3 maybe-root-4))))
My intuition is that maybe-root-3 and -4 are probably a bad idea to
include under Unix, but we can sort that out once things are working
for you.
Hope this helps. Let me know if I can be of better assistance.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
5:30 p.m.
Michael,
On 12/23/05, Michael Sperber <sperber(a)informatik.uni-tuebingen.de> wrote:
I can't find much fault with it, except for the code and work
duplication in between `paths-find-emacs-root' and your
`paths-find-potential-package-root'. My suggestion would be to rename
`paths-find-emacs-root' to `paths-find-invocation-roots' and have it
return a list instead of a single string. Approximately like so
(untested):
(defun paths-find-emacs-root (invocation-directory invocation-name)
"Find the run-time root of XEmacs.
INVOCATION-DIRECTORY is a directory containing the XEmacs executable.
INVOCATION-NAME is the name of the executable itself."
(let* ((executable-file-name (paths-chase-symlink
(concat invocation-directory
invocation-name)))
(executable-directory (file-name-directory executable-file-name))
(maybe-root-1 (file-name-as-directory
(paths-construct-path '("..")
executable-directory)))
(maybe-root-2 (file-name-as-directory
(paths-construct-path '(".." "..")
executable-directory)))
(maybe-root-3 (file-name-as-directory
(paths-construct-path '(".." "..")
executable-directory)))
(maybe-root-4 (file-name-as-directory
(paths-construct-path '(".." ".."
"..") executable-directory))))
(paths-filter #'paths-emacs-root-p
(list maybe-root-1 maybe-root-2 maybe-root-3 maybe-root-4))))
My intuition is that maybe-root-3 and -4 are probably a bad idea to
include under Unix, but we can sort that out once things are working
for you.
Thanks for your help. I should have mentioned that, based on your
earlier suggestions I had previously tried to make
`paths-find-emacs-root' return a list. At that time, I came across an
error like this one during dumping:
Loading e:\acs\software\src\xemacs-21.4-2005-12-23\lisp\dump-paths.el...***
Error in XEmacs initialization
(wrong-type-argument stringp
("e:\\acs\\software\\src\\xemacs-21.4-2005-12-23\\"))
*** Backtrace
really-early-error-handler((wrong-type-argument stringp
("e:\\acs\\software\\src\\xemacs-21.4-2005-12-23\\")))
file-name-as-directory(("e:\\acs\\software\\src\\xemacs-21.4-2005-12-23\\"))
(concat (file-name-as-directory root) suffix base)
(expand-file-name (concat (file-name-as-directory root) suffix base))
(file-name-as-directory (expand-file-name (concat ... suffix base)))
# bind (base suffix root)
paths-construct-emacs-directory(("e:\\acs\\software\\src\\xemacs-21.4-2005-12-23\\")
"lib\\xemacs-21.4.18\\" "lisp")
(let ((path ...)) (if (paths-file-readable-directory-p path) (throw
... path)))
# bind (root)
Based on your encouragement, this time I investigated further and
figured out that `paths-find-emacs-roots' was returning a list whose
first element was a list. dump-paths.el and `normal-top-level' in
startup.el (which call `paths-find-emacs-roots') could not handle that
complexity, so I hacked together a fix to flatten out the list at the
end of `paths-find-emacs-roots' and voila, the code works.
My hack doesn't feel like a particularly good lisp-y approach, so I
would be grateful for any help you or anyone else could offer. Here's
what I did: at the end of `paths-find-emacs-roots' I changed the code
from returning this form:
- (paths-filter #'paths-emacs-root-p potential-installation-roots)))
- (paths-uniq-append invocation-roots
- installation-roots)))
to this:
+ (paths-filter #'paths-emacs-root-p potential-installation-roots))
+ (maybe-not-flat (paths-uniq-append
+ invocation-roots
+ installation-roots)))
+ ; flatten the list and return it
+ (if (listp (car maybe-not-flat))
+ (nconc (car maybe-not-flat) (nthcdr 1 maybe-not-flat))
+ maybe-not-flat)))
It seems to me that the real problem is that `paths-uniq-append' does
not flatten the list it returns and it would be better to fix things
there, I think. Patches gratefully accepted.
One other comment, searching further up in the hierarchy was not
necessary, so I removed `maybe-root-4' from your sample code, and I
changed `maybe-root-3' to point to ../../XEmacs. This is the
directory that config.inc.samp defaults package installation to under
Windows.
The complete patch is attached. Please look this over and send me
your comments.
Thanks for your help.
Regards,
Vin
--
Whoever you are, no matter how lonely,
the world offers itself to your imagination,
calls to you like the wild geese, harsh and exciting--
over and over announcing your place
in the family of things. Mary Oliver
10:36 a.m.
Vin Shelton <acs(a)xemacs.org> writes:
Thanks for your help. I should have mentioned that, based on your
earlier suggestions I had previously tried to make
`paths-find-emacs-root' return a list. At that time, I came across an
error like this one during dumping:
Loading e:\acs\software\src\xemacs-21.4-2005-12-23\lisp\dump-paths.el...***
Error in XEmacs initialization
(wrong-type-argument stringp
("e:\\acs\\software\\src\\xemacs-21.4-2005-12-23\\"))
[...]
I assume you've converted the callers of what was
paths-find-emacs-root. It's hard to tell from looking at the
patch---I'm getting lost in a maze of revision changes since 21.4.
However, I can't see any change for (what I hope is) this code:
(defun paths-find-emacs-roots (invocation-directory
invocation-name
root-p)
"Find all plausible installation roots for XEmacs.
This is a list of plausible directories in which to search for the important
directories used by XEmacs at run-time, for example `exec-directory',
`data-directory' and `lisp-directory'.
ROOT-P is a function that tests whether a root is plausible."
(let* ((potential-invocation-root
(paths-find-emacs-root invocation-directory invocation-name))
(invocation-roots
(and potential-invocation-root
(list potential-invocation-root)))
...)))
You need to change the LET* binding to something like:
(let* ((invocation-roots
(paths-find-invocation-roots invocation-directory invocation-name))
...)
...)
Maybe I'm misunderstanding something---let me know if this helps.
Based on your encouragement, this time I investigated further and
figured out that `paths-find-emacs-roots' was returning a list whose
first element was a list.
That would be breaking the contract of `paths-find-emacs-roots'.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
6703
days inactive
6710
days old
5 comments
2 participants
participants (2)
-
Michael Sperber -
Vin Shelton