8:01 p.m.
PATCH 21.5
Cf. https://bugzilla.redhat.com/222559
"make install" installs canna_api.ell to MODPATH/canna_api.ell, but
canna-activate looks for it in MODPATH/canna/canna_api.ell. This patch
changes canna-activate to use the installed location.
Will commit in a few days unless there are objections.
2007-01-21 Ville Skyttä <scop(a)xemacs.org>
* mule/canna-leim.el (canna-activate): Look for canna_api, not
canna/canna_api to match actual installed location.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
4:18 a.m.
New subject: [Q21.5] Sync canna_api load/install paths
QUERY
Ville Skyttä writes:
PATCH 21.5
Cf. https://bugzilla.redhat.com/222559
"make install" installs canna_api.ell to MODPATH/canna_api.ell, but
canna-activate looks for it in MODPATH/canna/canna_api.ell. This patch
changes canna-activate to use the installed location.
I'm pretty sure that will break run-in-place, that's why the canna/
prefix is there (I mostly run in-place). This needs to be fixed
either in the module search code or in the module's make all or make
install targets.
Jerry, Mike, what do you think?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
4:11 p.m.
New subject: [Q21.5] Sync canna_api load/install paths
On Monday 22 January 2007 06:18, Stephen J. Turnbull wrote:
QUERY
Ville Skyttä writes:
> PATCH 21.5
>
> Cf. https://bugzilla.redhat.com/222559
>
> "make install" installs canna_api.ell to MODPATH/canna_api.ell, but
> canna-activate looks for it in MODPATH/canna/canna_api.ell. This patch
> changes canna-activate to use the installed location.
I'm pretty sure that will break run-in-place, that's why the canna/
prefix is there (I mostly run in-place).
Ok, intention to commit as is withdrawn at least for now, will apply only in
the Fedora packages as a band aid fix for the immediate problem.
This needs to be fixed
either in the module search code or in the module's make all or make
install targets.
Given the low number of available modules currently, I think the flat "make
install" (ie. all modules installed to one dir, no subdirs) is fine. No
opinions about running in-place, as I practically never do it. canna-leim
could of course try both canna_api and canna/canna_api but that's not too
clean.
BTW, without knowing much at all about the module search code and even less
about it on eg. Windows; does loading a hardcoded thing like "foo/bar" with
the forward slash path delimiter work on systems whose path delimiter is
something else?
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
10:10 a.m.
New subject: [Q21.5] Sync canna_api load/install paths
Ville Skyttä writes:
Given the low number of available modules currently, I think the flat
"make
install" (ie. all modules installed to one dir, no subdirs) is fine.
I think this needs thinking about. First, that means that
run-in-place and installed modules have to keep working differently,
and that's the source of the current problem.
Second, I hope to do something about the module population. I have
packaged up libneon and libcurl, which are just waiting for an
application and some refinement of a common API to go public (that's
three modules there). I'd like to do the same as canna with the wnn
and sj3 input methods. zlib and base64 should be actually done as
modules. It's possible that all the Mule codecs could be moved into
modules. (Lawd, lawd, I'd *love* to get that crap out of core!)
Third, some of the modules really ought to come with Lisp code (eg,
higher level UI for neon and curl).
BTW, without knowing much at all about the module search code and
even less
about it on eg. Windows; does loading a hardcoded thing like "foo/bar" with
the forward slash path delimiter work on systems whose path delimiter is
something else?
Ah, good point! I'll try to fix that. (Yes, it should work on
Windows; in fact Windows will accept either convention AFAIK. The
historical problem with / is that it is the MSDOS option character.)
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
2:52 p.m.
New subject: [Q21.5] Sync canna_api load/install paths
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Ville Skyttä writes:
> PATCH 21.5
>
> Cf. https://bugzilla.redhat.com/222559
>
> "make install" installs canna_api.ell to MODPATH/canna_api.ell, but
> canna-activate looks for it in MODPATH/canna/canna_api.ell. This patch
> changes canna-activate to use the installed location.
I'm pretty sure that will break run-in-place, that's why the canna/
prefix is there (I mostly run in-place). This needs to be fixed
either in the module search code or in the module's make all or make
install targets.
Jerry, Mike, what do you think?
I think Ville's patch is OK, but the load-path depth for modules needs
to be >0, as in the attached patch.
2007-01-27 Mike Sperber <mike(a)xemacs.org>
* setup-paths.el (paths-module-load-path-depth): Add.
* setup-paths.el (paths-construct-module-load-path): For
`module-load-path', use `paths-module-load-path-depth', not
`paths-core-load-path-depth'.
Could somebody try this out and make sure it works?
I guess there's a whole bunch of instances where locating a module
specifies an explicit prefix, which it shouldn't. Maybe Jerry can
shed some light on how things are supposed to hang together?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Index: lisp/setup-paths.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/xemacs/lisp/setup-paths.el,v
retrieving revision 1.22
diff -u -r1.22 setup-paths.el
--- lisp/setup-paths.el 14 Mar 2006 00:09:03 -0000 1.22
+++ lisp/setup-paths.el 27 Jan 2007 14:50:05 -0000
＠＠ -55,6 +55,9 ＠＠
(defvar paths-mule-load-path-depth 0
"Depth of load-path searches in Mule Lisp paths.")
+(defvar paths-module-load-path-depth 1
+ "Depth of load-path searches in module paths.")
+
(defvar paths-default-info-directories
(mapcar (function
(lambda (dirlist)
＠＠ -243,7 +246,7 ＠＠
(module-load-path
(and module-directory
(paths-find-recursive-load-path (list module-directory)
- paths-core-load-path-depth))))
+ paths-module-load-path-depth))))
(append env-module-path
site-module-load-path
module-load-path)))
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
6:56 p.m.
New subject: [C 21.5] Sync canna_api load/install paths
COMMIT
On Sunday 21 January 2007 22:01, Ville Skyttä wrote:
PATCH 21.5
Cf. https://bugzilla.redhat.com/222559
"make install" installs canna_api.ell to MODPATH/canna_api.ell, but
canna-activate looks for it in MODPATH/canna/canna_api.ell. This patch
changes canna-activate to use the installed location.
Committed per Stephen's approval in another related thread. Thanks Stephen
and Mike.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
6523
days inactive
6544
days old
5 comments
3 participants
participants (3)
-
Michael Sperber -
Stephen J. Turnbull -
Ville Skyttä