XEmacs Binary Kit HOWTO, V21.1
::::::::::::::
INTRODUCTION
::::::::::::::
These instructions are meant to assist XEmacs developers in the
preparation of precompiled XEmacs binary-kits. If you plan on
building a binary-kit for the XEmacs project, please join the
xemacs-binary-kits mailing list. This is a seasonal, low volume list
for discussion among XEmacs binary-kit builders, and announcements
from the binary-kit coordinator. To subscribe to xemacs-binary-kits,
send an email message to <xemacs-binary-kits-request@xemacs.org> with
`subscribe' as the BODY of the message.
Also, please take the time to read this file in its entirety before
starting to prepare your binary-kit. If the binary-kit you prepare
doesn't conform to the guidelines herein, you will be kindly asked to
redo it. If you have questions about anything, please ask on the
mailing list.
::::::::::::::
NEWS
::::::::::::::
Several things about the XEmacs binary-kit preparation process have
changed since the 20.4 release.
For prior versions of the binary-kits, architecture-independent tar
files containing the `lisp', `etc' and `info' directories were
distributed along with the architecture-dependent tar file containing
the executables. These "common" files have been done away with to
allow for a simpler binary-kit installation in the face of the new
package system. As of this release, core lisp, executables as well as
the man, etc, and info directories will be distributed together in one
tarball. This means one will only have to download at most a total of
two or three tarballs to install a binary-kit. One tarball for the
particular architecture, one tarball for the regular Sumo-lisp, and
(optionally) one tarball for MULE.
::::::::::::::
BUILDING
::::::::::::::
The procedures for building a MULE-enabled and a non-mule-enabled
XEmacs binary-kit differ slightly. Please take careful note of the
differences.
Latin-1 binary kits (non-MULE)
==============================
Do your builds with:
CONFIG=`./config.guess`
% ./configure $CONFIG --prefix=/usr/local
--bindir=/usr/local/bin/$CONFIG
If you need to install somewhere other than /usr/local, set USRLOCAL
to your preferred local installation directory and run:
% make prefix=$USRLOCAL bindir=$USRLOCAL/bin/$CONFIG install
The optimal Latin-1 binary kit would be built with at least the
following options to configure:
--with-menubars=lucid
--with-scrollbars=lucid
--with-dialogs=motif if you have Motif
--with-xpm
--with-xface
--with-tooltalk if you've got it
--with-sound=native if your system has it
--with-sound=both if you've got netaudio (else don't sweat it)
--with-gif
--with-png
--with-jpeg
--with-tiff if you've got it
--with-database=dbm if you've got it
--with-cde if you've got it
MULE binary kits
================
For MULE-enabled binary-kits,
Do your builds with:
CONFIG=`./config.guess`
% ./configure $CONFIG --prefix=/usr/local
--bindir=/usr/local/bin/$CONFIG-mule
If you need to install somewhere other than /usr/local, set USRLOCAL
to your preferred local installation directory and run:
% make prefix=$USRLOCAL bindir=$USRLOCAL/bin/$CONFIG-mule install
The optimal MULE binary kit would be built with the same options to
configure as the Latin-1 binary kit options shown above, but
_in addition_ add the following options:
--with-mule=yes
--with-cde=no
--with-wnn if you've got it
--with-canna if you've got it
and possibly
--with-wnn6 see below
If you build with Motif you automatically get XIM. Wnn4 is somewhat
of a pain to build so for this first go around if you can't get it
built don't sweat it. If you build with Canna, make sure it is 3.2
and not 3.5beta as per the wishes of the developers.
Wnn4 and Wnn6 are mutually exclusive -- you can't put both in the same
XEmacs. There have been reports of running a MULE binary with Canna
and Wnn4/Wnn6 for nearly a near without problems.
The Wnn6 SDK is at
ftp://ftp-sp.omronsoft.co.jp/pub/Wnn6/sdk/
This consists of a static library and header files.
Canna and Wnn can safely coexist in one binary. Canna, Wnn4.2/Wnn6 and
XIM=xlib have been tested in a single binary without difficulty. Note
that on Linux the Wnn6 library from Omron definitely works when XEmacs
is linked against glibc2. XIM=xlib has been tested with kinput2 as
the XIM server and works.
We recommend building `--with-xfs=yes' if either your C library
supports localization, or your X11 libraries were built with X_LOCALE
defined.
ALL binary-kits (both MULE and non-MULE)
========================================
* Compile with the highest level of optimization you feel comfortable
* with.
* Please avoid the `-fast' SunPro compiler option on Solaris.
* We recommend not using GCC if you don't have to. Better seems to be
* EGCS, the successor to GCC. We have not tested pgcc built binaries
* on anything other than a Pentium, nor are we aware of anyone else
* who has. So we recommend avoiding pgcc even for ix86 Linux/BSD.
* Also make sure *NOT* to strip the binary. A stack backtrace should
* at least show the names of the functions on the stack (the default
* behavior without -g).
* If you don't have Motif then build with Athena dialogs instead. Do
* not change the menubar or scrollbar toolkit without mentioning
* something first.
* We are taking a harder stance on dynamic kits for this release.
* They appear to have given us far more grief than benefit. Remember,
* the idea on the kits is not that they are the preferred way to use
* XEmacs, but that they are the path-of-least-effort and should work
* everywhere. Think static!, static!, static! before building a
* binary kit. At minimum, any standard system library may be
* dynamically linked. Any library which might not be installed on a
* system MUST be statically linked. Let me repeat that. ANY library
* which might not be installed on a system MUST be statically linked.
* Basically if a library doesn't get installed when doing the most
* minimal install of the OS, or if there is quite a bit of variation
* between installations of the OS (e.g. Linux) then you should be
* linking statically.
* Libraries which should definitely be statically linked include:
XPM
compface
Motif
JPEG
PNG/z
TIFF
Canna/RKC
Wnn4
Wnn6
* Also, ncurses and the db libraries should probably be statically linked.
* If you do link dynamically, try VERY VERY hard to link against the
* oldest possible versions of the libraries.
* If you use something like Athena3d, that's fine, but make sure the
* thing is statically linked.
* Use the "ldd" command or your system equivalent on all of the
* executables (xemacs itself, and the lib-src executables) to verify
* that they are linked the way you think they are linked.
::::::::::::::
READMEs
::::::::::::::
Before you archive the contents of the install directory, you should
add a README file to the top level directory.
The README file that you include should be named:
README.$CONFIG (for Latin-1 kits)
README.$CONFIG-mule (for MULE kits)
Two example READMEs are included in the same directory as this file:
`README.i686-pc-linux' and `README.i686-pc-linux-mule'.
Your README should look approximately like these, with appropriate
query-replace results. However, do mention anything else you think
needs to be mentioned.
::::::::::::::
PACKAGING
::::::::::::::
Now go ahead and package up your binary-kit. Your gzipped tar file
should be named:
xemacs-21.1.3-$CONFIG.tar.gz (for Latin-1 kits)
xemacs-21.1.3-$CONFIG-mule.tar.gz (for MULE kits)
For example, where $CONFIG is `i686-pc-linux':
xemacs-21.1.3-i686-pc-linux.tar.gz
xemacs-21.1.3-i686-pc-linux-mule.tar.gz
Their top level directory structure should look similar to the
following:
README.$CONFIG (README.$CONFIG-mule for MULE kits)
bin/$CONFIG (bin/$CONFIG-mule for MULE kits)
lib/xemacs-21.1-p3/
lib/xemacs-21.1-p3/etc
lib/xemacs-21.1-p3/lisp
lib/xemacs-21.1-p3/info
lib/xemacs-21.1-p3/$CONFIG
lib/xemacs
lib/xemacs/lock
man/man1
This is essentially the directory setup that you will get when you do
a "make install".
::::::::::::::
TESTING
::::::::::::::
Once you have created your packaged binary-kit, please attempt an
installation as described in your README as if you were an end user.
Please try this on a different different machine if at all possible to
verify portability.
::::::::::::::
UPLOADING
::::::::::::::
When you're done, please upload the following THREE items into:
ftp://ftp.xemacs.org/pub/xemacs/beta/incoming/binary-kits/
1. Your tarred, gzipped binary kit.
2. The "Installation" file that was created during the build.
3. A copy of your README.$CONFIG (or README.$CONFIG-mule).
NOTE: When uploading binary kits, you will need to login to
ftp.xemacs.org with the FTP username `xemacs', password `zawinski'
(not anonymous!) in order to write to the binary-kits directory. Once
logged in, cd to /pub/xemacs/beta/incoming/binary-kits/ and start the
upload.
Finally, please send a message to <kit-manager@xemacs.org> letting me
know what you dropped off so your kit can be processed.
Thank-you for your contribution!
--
kit-manager@xemacs.org