9:52 a.m.
Can it be done while you've got regular Gnus in xemacs-packages? Can
it be done at all? I'm getting a broken build because Gnus can't find
its own files (nndiary.el, presumably that's new in oort).
I noticed that there is probably a generic bug in XEmacs.rules, or
maybe package-compile.el. That is that all dependencies _including
the self-dependency_ come from xemacs-packages, not site-packages. So
the autoloads come from xemacs-packages/gnus/gnus/lisp/auto-autoloads
and the load-path contains xemacs-packages/gnus/gnus/lisp/, not
site-packages/oort-gnus/gnus/lisp/auto-autoloads and
site-packages/oort-gnus/gnus/lisp/.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
10:24 a.m.
Stephen J. Turnbull wrote:
I'm getting a broken build because Gnus can't find its own
files
(nndiary.el, presumably that's new in oort).
Correct. I can't answer your question though, because I don't install
the Gnus that's in xemacs-packages.
BTW: something boring with the packages is that when you don't want to install
one, it seems that compiling it is still required.
--
Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 22
94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 53 14 59 22 didier(a)xemacs.org
11:27 a.m.
New subject: Kids, Don't Try This At Home Fix: Building oort Gnus in site-packages
>>>> "drv" == Didier Verna
<didier(a)xemacs.org> writes:
drv> Stephen J. Turnbull wrote:
> I'm getting a broken build because Gnus can't find its
own
> files (nndiary.el, presumably that's new in oort).
drv> Correct. I can't answer your question though, because
drv> I don't install the Gnus that's in xemacs-packages.
OK. Figured out how to hack this. Patch below. This one isn't for
xemacs-patches yet, though.
drv> BTW: something boring with the packages is that when you
drv> don't want to install one, it seems that compiling it is
drv> still required.
I don't understand. If you build from the top, yes, but if you build
in the package directory (which unfortunately can fail), it should
work OK whether other packages are compiled or not.
Here's the patch. My oort lives in site-packages/oort-gnus, but
otherwise is a standard XEmacs Gnus hierarchy. The variable
SITEPACKAGEDIRECTORYMAP needs to be set to a list of conses of package
name (as a string) and hierarchy root (as a string), eg in bash
$ export SITEPACKAGEDIRECTORYMAP='(("oort-gnus" .
"site-packages"))'
I suppose there should be a way to do this in the Makefile but the
obvious try (commented out) didn't work right. You also need to hack
package-compile.el (besides the part that gets this environment
variable) to map oort-gnus's lisp directory to gnu/lisp.
There are a few miscellaneous ickinesses that need changed too (like
the disappearance and appearance of a few texi files).
Index: package-compile.el
===================================================================
RCS file: /pack/xemacscvs/XEmacs/packages/package-compile.el,v
retrieving revision 1.51
diff -u -r1.51 package-compile.el
--- package-compile.el 4 Oct 2002 22:04:18 -0000 1.51
+++ package-compile.el 22 Oct 2002 10:21:34 -0000
＠＠ -61,6 +61,7 ＠＠
(require 'bytecomp)
(defconst package-directory-map
+ (append (read (getenv "SITEPACKAGEDIRECTORYMAP"))
'(
;; xemacs-packages
("Sun" . "xemacs-packages")
＠＠ -176,8 +177,9 ＠＠
("lookup" . "mule-packages")
("mule-base" . "mule-packages")
("mule-ucs" . "mule-packages")
- ("skk" . "mule-packages")))
-
+ ("skk" . "mule-packages"))
+ ) ; (append ...
+ )
(defun package-name-to-directory (package)
"Map `package' to a source directory."
＠＠ -187,6 +189,8 ＠＠
package-directory-map))
"../.."))))
(cond ((equal package "gnus")
+ (expand-file-name "gnus/lisp" (file-name-as-directory dir)))
+ ((equal package "oort-gnus")
(expand-file-name "gnus/lisp" (file-name-as-directory dir)))
((or (equal package "w3")
(equal package "bbdb")
--- xemacs-packages/gnus/Makefile 2002-10-18 07:22:56.000000000 +0900
+++ site-packages/oort-gnus/Makefile 2002-10-22 19:25:21.000000000 +0900
＠＠ -17,19 +17,21 ＠＠
# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
-VERSION = 1.64
-AUTHOR_VERSION = 5.8.8
-MAINTAINER = XEmacs Development Team <xemacs-beta(a)xemacs.org>
-PACKAGE = gnus
+VERSION = 0.10
+AUTHOR_VERSION = 0.07
+
+#special stuff
+MAINTAINER = Stephen J. Turnbull <stephen(a)xemacs.org>
+PACKAGE = oort-gnus
+#SITEPACKAGEDIRECTORYMAP = (("oort-gnus" . "site-packages"))
+REQUIRES = $(PACKAGE) w3 mh-e mailcrypt rmail eterm sh-script dired \
+ mail-lib xemacs-base fsf-compat
+
PKG_TYPE = regular
-REQUIRES = gnus w3 mh-e mailcrypt rmail eterm mail-lib xemacs-base fsf-compat \
- ecrypto
CATEGORY = standard
LISPFILES = $(wildcard gnus/lisp/*.el)
ELCS = $(LISPFILES:.el=.elc)
-EXTRA_SOURCES = gnus/lisp/md5.el.upstream
-
DATA_FILES = $(wildcard etc/sounds/*.au) $(wildcard etc/sounds/*.wav)
DATA_DEST = sounds
DATA_1_FILES = $(wildcard etc/message/*.x?m)
＠＠ -45,9 +47,8 ＠＠
INFO_FILES = gnus/texi/message.info* gnus/texi/gnus.info* \
gnus/texi/emacs-mime.info*
-TEXI_FILES = gnus/texi/message.texi gnus/texi/gnus.texi \
- gnus/texi/gnus-faq.texi gnus/texi/gnusmail.texi \
- gnus/texi/emacs-mime.texi
+TEXI_FILES = gnus/texi/*.texi
+MANUALS = gnus message emacs-mime
MAKEINFO_FLAGS = -Ignus/texi
＠＠ -65,6 +66,9 ＠＠
html:
cd gnus/texi && $(MAKE) html
-.PHONY: binkit
+.PHONY: srckit binkit
+
+srckit:
+ ＠echo "You can't build a source kit for Gnus this way"
binkit: binkit-common
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8:07 p.m.
New subject: Kids, Don't Try This At Home Fix: Building oort Gnus in site-packages
On Tue, 2002-10-22 at 13:27, Stephen J. Turnbull wrote:
drv> BTW: something boring with the packages is that when you
drv> don't want to install one, it seems that compiling it is
drv> still required.
I don't understand. If you build from the top, yes, but if you build
in the package directory (which unfortunately can fail), it should
work OK whether other packages are compiled or not.
...and if it doesn't work, you'll need to add some "indirect" REQUIRES
entries. Meaning that the package you're building doesn't need those
REQUIRES itself, but some of its real requirements do. Sigh...
Here's the patch. My oort lives in site-packages/oort-gnus, but
otherwise is a standard XEmacs Gnus hierarchy.
Hmm, now I don't understand; site-packages? Why introduce a new build
dir and not use unsupported/stephen for that? The packages built from
unsupported/ will land nicely in UNSUPPORTED_STAGING, which defaults to
${UNSUPPORTED_PACKAGES_BASE}/../../site-packages. See
unsupported/Local.rules.mk.
Be sure to set package-info.in (distribution) and Makefile (CATEGORY) to
"unsupported" and it'll work just fine. And do the other tweaks to the
files under unsupported/ too (eg. package-compile.el
(package-directory-map)).
+MANUALS = gnus message emacs-mime
[...]
+.PHONY: srckit binkit
+
+srckit:
+ ＠echo "You can't build a source kit for Gnus this way"
The source targets and MANUAL stuff were removed last week from the
packages tree, be sure that you're using up to date build files as
templates...
--
\/ille Skyttä
scop at xemacs.org
5:26 a.m.
New subject: Kids, Don't Try This At Home Fix: Building oort Gnus in site-packages
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> Hmm, now I don't understand; site-packages?
Ville> Why introduce a new build dir
It's not new. site-packages have been around for pretty much as long
as the package system has. There needs to be a place for stuff that
sys admins can put local/3rd party packages. This where I've put my
own stuff for about 3 years now. When I'm ready to check in to CVS, I
just move it over to {xemacs,mule}-packages.
Ville> and not use unsupported/stephen for that?
It never occurred to me to use unsupported that way. I think of
unsupported/stephen as a staging area for my experimental packages
that others might like to play with, not as where I put somebody
else's beta packages that I'm testing.
BTW, I'm not sure I like the idea of anything we distribute, including
unsupported/, defaulting to installing in site-*/. The FHS says about
/usr/local:
This directory should always be empty after first installing a
FHS-compliant system. No exceptions to this rule should be made other
than the listed directory stubs.
I don't see why XEmacs shouldn't have the same rights and
responsibilities as any other fully capable operating system. :-)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
7:15 p.m.
New subject: Kids, Don't Try This At Home Fix: Building oort Gnus in site-packages
On Wed, 2002-10-23 at 07:26, Stephen J. Turnbull wrote:
Ville> Hmm, now I don't understand; site-packages?
Ville> Why introduce a new build dir
It's not new. site-packages have been around for pretty much as long
as the package system has. There needs to be a place for stuff that
sys admins can put local/3rd party packages. This where I've put my
own stuff for about 3 years now. When I'm ready to check in to CVS, I
just move it over to {xemacs,mule}-packages.
Ah, I see. "grep site-packages *" in packages/ produces no hits, that's
what made me wonder what you're talking about.
Ville> and not use unsupported/stephen for that?
It never occurred to me to use unsupported that way. I think of
unsupported/stephen as a staging area for my experimental packages
that others might like to play with, not as where I put somebody
else's beta packages that I'm testing.
...and I think of it pretty much as the opposite :). Anyway, it
obviously can be used for both of purposes.
BTW, I'm not sure I like the idea of anything we distribute,
including
unsupported/, defaulting to installing in site-*/.
I'm fine with changing this, just go ahead if it bugs you.
unsupported-packages?
But strictly speaking, IMHO we're not distributing anything under
unsupported/. It's stuff that just lives in our CVS, and doesn't even
get checked out if using the "packages" module, as the instructions
advise to do. (Too bad a subsequent "cvs update -d" will bring it into
the working dir. CVS modules suck sometimes.)
I don't see why XEmacs shouldn't have the same rights and
responsibilities as any other fully capable operating system. :-)
Hey, where's my "Boot XEmacs" CD... :)
--
\/ille Skyttä
scop at xemacs.org
3:51 a.m.
New subject: Kids, Don't Try This At Home Fix: Building oort Gnus in site-packages
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> ...and I think of it pretty much as the opposite :).
Ville> Anyway, it obviously can be used for both of purposes.
OK.
> BTW, I'm not sure I like the idea of anything we distribute,
> including unsupported/, defaulting to installing in site-*/.
Ville> I'm fine with changing this, just go ahead if it bugs
Ville> you. unsupported-packages?
Actually, I was thinking in terms of xemacs-packages. Most of the
stuff in unsupported ends up being moved to xemacs-packages. For
stuff that we probably never will support, I prefer the name
"contrib".
That's not important. However, we badly need an uninstall target in
XEmacs.rules. For Unix, finding the MANIFEST.$package and doing `cat
MANIFEST.$package | xargs rm -f' works, I bet. Dunno about Windows
though.
Ville> But strictly speaking, IMHO we're not distributing anything
Ville> under unsupported/. It's stuff that just lives in our CVS,
CVS is one of our primary modes of distribution now. We're a free
software project; to me that implies we distribute everything we do,
perhaps with some evaluation as to whether you really want to take it
or not. :-)
> I don't see why XEmacs shouldn't have the same rights
and
> responsibilities as any other fully capable operating system.
> :-)
Ville> Hey, where's my "Boot XEmacs" CD... :)
chsh -s /usr/bin/xemacs comes pretty close. (This used to work, have
tried it recently though.)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
8:16 a.m.
New subject: Kids, Don't Try This At Home Fix: Building oort Gnus in site-packages
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
SJT> chsh -s /usr/bin/xemacs comes pretty close. (This used to
SJT> work, have tried it recently though.)
Yep, still does. :-)
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:24 a.m.
|--==> "SJT" == Stephen J Turnbull <stephen(a)xemacs.org> writes:
SJT> Can it be done while you've got regular Gnus in xemacs-packages?
SJT> Can it be done at all?
Of course it can...
,----[ Oort's ChangeLog ]
| 2002-04-26 Steve Youngs <youngs(a)xemacs.org>
|
| * aclocal.m4 (AC_PATH_INFODIR): New. Defaults to '$prefix/info'
| for Emacs and 'site-packages/info' for XEmacs.
| (AC_PATH_ETCDIR): Drop 'gnus' off the end of the default directory
| for XEmacs.
|
| * configure.in: Use 'AC_PATH_INFO_DIR'.
|
| 2002-02-22 Steve Youngs <youngs(a)xemacs.org>
|
| * aclocal.m4 (AC_PATH_LISPDIR): Default to
| .../site-packages/lisp/gnus for XEmacs.
| (AC_PATH_ETCDIR): Default to .../site-packages/etc/gnus for
| XEmacs.
`----
Which means...
- 'cvs up' (in your Oort workspace)
- ./configure (most people won't need to specify any opts)
- 'make'
- 'make install'
And you'll end up with Oort Gnus installed in the correct directories
under <emacs-roots>/lib/xemacs/site-packages/
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8026
days inactive
8032
days old
8 comments
4 participants
participants (4)
-
Didier Verna -
Stephen J. Turnbull -
Steve Youngs -
Ville Skyttä