February 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Building packages from source not quite possible 25 years, 3 months

Colin Rafferty

Carsten Leonhardt writes: >>> The problem is that building tm depends on being able to load the >>> auto-autoloads from rmail, and vice-versa. As a result, bbdb can't be >>> built, as this depends on the auto-autoloads from tm. Colin> I didn't realize that this was the case. Colin> Could you please let me know how BBDB depends on tm. > Well, apparently it doesn't. I just removed "apel" and "tm" from the > REQUIRES line in the Makefile, and it bytecompiles without error. What Makefile has this REQUIRES line? Is this something that is in distributed with the BBDB package, something in XEmacs packages, or something that you did? -- Colin

1 participants
0 comments

Re: --no-split and XEmacs mode 25 years, 3 months

Didier Verna

Akim Demaille writes: Akim> I don't know too well where the bug is, but depending whether makeinfo Akim> is called with --no-split or not, the Emacs info mode is unable to Akim> recognize the `g' Goto command (it recognizes no node). The bad case Akim> being --no-split. Akim> A typical example is autoconf.info, which is --no-split. The Tag table Akim> is output in both cases, but not at the same place. I'm not sure the --no-split is the origin of the problem, but I'm sure the bug is in info.el. For some reason, Info-build-node-completions can get a tag table marker whose buffer is the *info* buffer itself, not another one that you could get if the file is indirect. In that case, it tries to go to the marker position without the buffer being widended, and thus fails finding the tag table. Here's a half-blind fix. Half-blind because I don't really know if we should always have another buffer for the tag table or not. 1999-02-12 Didier Verna <verna(a)inf.enst.fr> * info.el (Info-build-node-completions): unconditionally widen the tag table buffer. --- lisp/info.el.orig Fri Feb 12 19:36:34 1999 +++ lisp/info.el Fri Feb 12 19:37:03 1999 ＠＠ -1542,6 +1542,7 ＠＠ (let ((compl (Info-build-annotation-completions))) (save-excursion (save-restriction + (widen) (if (marker-buffer Info-tag-table-marker) (progn (set-buffer (marker-buffer Info-tag-table-marker)) ＠＠ -1551,7 +1552,6 ＠＠ (cons (list (buffer-substring (match-beginning 1) (match-end 1))) compl)))) - (widen) (goto-char (point-min)) (while (search-forward "\n\^_" nil t) (forward-line 1) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: XEmacs 21.2.10 on AIX 4.3.1 ??? 25 years, 3 months

Michael Sperber

>>>>> "Derek" == Derek Scherger <derek(a)echologic.com> writes: Derek> Also, note that I had to add "#define USE_DL_STUBS 1" to Derek> src/s/aix4-2.h to make the linker happy about dlsym and dlopen. This is strange. AIX has shipped with dlsym and dlopen since 4.2.1. What exactly is the problem? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Building packages from source not quite possible 25 years, 3 months

Carsten Leonhardt

Jan> Mule is special because it is not a real package. It is really Jan> software that should be in the main lisp directory and tarball but Jan> isn't because we want non-Mule user to spare download time and disk Jan> space. The files that are loaded from mule-base during dumping are only a subset of the contents of the mule-base package. They are 193kb uncompressed, 43603 bytes tared & gzipped. Does that size warrant these complications? (And the non-Mulers get the *.c files, anyway)

2 participants
1 comments

Re: Building packages from source not quite possible 25 years, 3 months

Carsten Leonhardt

>> The problem is that building tm depends on being able to load the >> auto-autoloads from rmail, and vice-versa. As a result, bbdb can't be >> built, as this depends on the auto-autoloads from tm. Colin> I didn't realize that this was the case. Colin> Could you please let me know how BBDB depends on tm. Well, apparently it doesn't. I just removed "apel" and "tm" from the REQUIRES line in the Makefile, and it bytecompiles without error.

1 participants
0 comments

Problems with ftp.xemacs.org 25 years, 3 months

Jan Vroonhof

Am I the only one having problems with ftp.xemacs.org? Typically one in three retrievals never finishes. Or to be more precise the file seems to get there completely[1] but the ftp client (and therefore EFS) never signals the end of the transfer. I thought it could be some local configuration problem, however I am not at my girlfriends university and there the same problem occur. All the transfers seem to be pretty quick so it does not seem to be a congestion problem (at least not in the ftp.xemacs.org->*.ch direction). Jan Footnotes: [1] Typically a restart in a package install has a package with a valid MD5 sitting in the incoming directory.

3 participants
2 comments

Re: Building packages from source not quite possible 25 years, 3 months

Jan Vroonhof

Carsten Leonhardt <leo(a)arioch.oche.de> writes: > Jan> Of course. That is the whole idea. In fact last time I built an XEmacs > Jan> from scratch that was also the case. What is the problem? > > I build with mule. > AFAIK, you cannot build a Mule-enabled binary > without having the compiled mule-base package around, which you cannot > generate without a Mule-enabled XEmacs... Mule is special because it is not a real package. It is really software that should be in the main lisp directory and tarball but isn't because we want non-Mule user to spare download time and disk space. However Mule doesn't _need) the _compiled_ package, it just needs the files around. Maybe the Makefiles need to be tweaked to allow a Mule XEmacs to build with just the uncompiled Mule elcs around. I guess the only thing needed for that is a target in the mule-base package Makefile to allow a "package build" that does but produce elcs. The result should be sufficient to bootstrap a Mule XEmacs. Alternatively it should be possible to build the packages using temacs. Jan

1 participants
0 comments

Re: Building packages from source not quite possible 25 years, 3 months

Colin Rafferty

Carsten Leonhardt writes: > The problem is that building tm depends on being able to load the > auto-autoloads from rmail, and vice-versa. As a result, bbdb can't be > built, as this depends on the auto-autoloads from tm. I didn't realize that this was the case. Could you please let me know how BBDB depends on tm. -- Colin

1 participants
0 comments

Re: Building packages from source not quite possible 25 years, 3 months

Carsten Leonhardt

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Of course. That is the whole idea. In fact last time I built an XEmacs Jan> from scratch that was also the case. What is the problem? I build with mule. AFAIK, you cannot build a Mule-enabled binary without having the compiled mule-base package around, which you cannot generate without a Mule-enabled XEmacs... The other packages that need to be dumped (egg-its and skk, I think), are not that problematic, because you rebuild XEmacs once you compiled them. Jan> You points about building the packages from source are valid. However Jan> the current situation is already an improvement. It used to be that Jan> you could ONLY build ALL the packages from scratch. The clever preload Jan> stuff needed for that made it in impossible to build just a single Jan> package. Moreover you needed yo make your environment almost an exact Jan> copy of that of Steve's. These requirements no longer apply. If this Jan> has been achieved at the cost of only some fixable dependency problems Jan> in the from-scratch build that is a positive thing. I just found out it fails for me (with Stephen Turnbull's hints leading the way). I build the packages (from a clean source) with make STAGING=/home/xemacs/package-staging bindist The bindist rule doesn't build the autoloads beforehand (like "make all" does), and therefore fails like that. Maybe one should have a target "autoloads", and have bindist depend on that. Doing a "make all; make bindist" sucks, because then some packages get bytecompiled twice, and it takes long enough already. leo

1 participants
0 comments

--no-split and XEmacs mode 25 years, 3 months

Akim Demaille

Hi! I don't know too well where the bug is, but depending whether makeinfo is called with --no-split or not, the Emacs info mode is unable to recognize the `g' Goto command (it recognizes no node). The bad case being --no-split. A typical example is autoconf.info, which is --no-split. The Tag table is output in both cases, but not at the same place. I use: ;;; info.el --- info package for Emacs. ;; Keywords: help ;; Copyright (C) 1985, 1986, 1993, 1997 Free Software Foundation, Inc. ;; Author: Dave Gillespie <daveg(a)synaptics.com> ;; Richard Stallman <rms(a)gnu.ai.mit.edu> ;; Maintainer: Dave Gillespie <daveg(a)synaptics.com> ;; Version: 1.07 of 7/22/93 ;; Keywords: docs, help ........ ;; Modified 1998-03-29 by Oscar Figueiredo ;; ;; Added automatic dir/localdir (re)building capability for directories that ;; contain none or when it has become older than info files in the same ;; directory. ;; Modified 1998-09-23 by Didier Verna <verna(a)inf.enst.fr> ;; ;; Use the new macro `with-search-caps-disable-folding' Akim -- P-mail: Akim Demaille, 107 rue Bobillot, F-75013 Paris, France E-mail: demaille(a)inf.enst.fr V-mail: +33 1 45 81 78 81

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta February 1999