Anonymous avatar Anonymous committed 5a79be0

Import from CVS: tag r21-0b46

Comments (0)

Files changed (21)

 							-*- indented-text -*-
+to 21.0 pre3 "Toggenburg"
+-- Configure changes to handle Berkeley DB 2 from Kazuyuki IENAGA and Martin
+   Buchholz
+-- 64 bit cleanliness fix from Olivier Galibert
+-- Package Documentation from Michael Sperber
+-- Cygwin font lossage fix from Andy Piper
+
 to 21.0 pre2 "Thuringian"
 -- MS Windows native build fixes from Fabrice POPINEAU
 -- Miscellaneous bug fixes
+1998-06-19  SL Baur  <steve@altair.xemacs.org>
+
+	* XEmacs 21.0-pre3 is released.
+
+1998-06-20  Michael Sperber [Mr. Preprocessor]  <sperber@informatik.uni-tuebingen.de>
+
+	* etc/PACKAGES: 
+	* etc/BETA: Moved some package stuff into Texinfo docs.  Other nitpicks
+
+1998-06-20  Kazuyuki IENAGA <ienaga@jsys.co.jp>
+
+	* configure.in: Added check if the berkdb has db_open or not.
+	(With fixes from Martin Buchholz)
+
 1998-06-19  SL Baur  <steve@altair.xemacs.org>
 
 	* XEmacs 21.0-pre2 is released.
   with_database_berkdb=yes need_libdb=no
 else
   echo "$ac_t""no" 1>&6
-fi
-
-  if test "$need_libdb" != "no"; then
-    
+echo $ac_n "checking for db_open""... $ac_c" 1>&6
+echo "configure:10824: checking for db_open" >&5
+
+cat > conftest.$ac_ext <<EOF
+#line 10827 "configure"
+#include "confdefs.h"
+/* System header to define __stub macros and hopefully few prototypes,
+    which can conflict with char db_open(); below.  */
+#include <assert.h>
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+char db_open();
+
+int main() {
+
+/* The GNU C library defines this for functions which it implements
+    to always fail with ENOSYS.  Some functions are actually named
+    something starting with __ and the normal name is an alias.  */
+#if defined (__stub_db_open) || defined (__stub___db_open)
+choke me
+#else
+db_open();
+#endif
+
+; return 0; }
+EOF
+if { (eval echo configure:10850: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+  rm -rf conftest*
+  eval "ac_cv_func_db_open=yes"
+else
+  echo "configure: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_func_db_open=no"
+fi
+rm -f conftest*
+
+if eval "test \"`echo '$ac_cv_func_'db_open`\" = yes"; then
+  echo "$ac_t""yes" 1>&6
+  with_database_berkdb=yes need_libdb=no
+else
+  echo "$ac_t""no" 1>&6
+
 echo $ac_n "checking for dbopen in -ldb""... $ac_c" 1>&6
-echo "configure:10828: checking for dbopen in -ldb" >&5
+echo "configure:10868: checking for dbopen in -ldb" >&5
 ac_lib_var=`echo db'_'dbopen | sed 'y%./+-%__p_%'`
 
 xe_check_libs=" -ldb "
 cat > conftest.$ac_ext <<EOF
-#line 10833 "configure"
+#line 10873 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
 dbopen()
 ; return 0; }
 EOF
-if { (eval echo configure:10844: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:10884: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
   with_database_berkdb=yes need_libdb=yes
 else
   echo "$ac_t""no" 1>&6
-fi
-
-
-    fi
+echo $ac_n "checking for db_open in -ldb""... $ac_c" 1>&6
+echo "configure:10902: checking for db_open in -ldb" >&5
+ac_lib_var=`echo db'_'db_open | sed 'y%./+-%__p_%'`
+
+xe_check_libs=" -ldb "
+cat > conftest.$ac_ext <<EOF
+#line 10907 "configure"
+#include "confdefs.h"
+/* Override any gcc2 internal prototype to avoid an error.  */
+/* We use char because int might match the return type of a gcc2
+    builtin and then its argument prototype would still apply.  */
+char db_open();
+
+int main() {
+db_open()
+; return 0; }
+EOF
+if { (eval echo configure:10918: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=yes"
+else
+  echo "configure: failed program was:" >&5
+  cat conftest.$ac_ext >&5
+  rm -rf conftest*
+  eval "ac_cv_lib_$ac_lib_var=no"
+fi
+rm -f conftest*
+xe_check_libs=""
+
+if eval "test \"`echo '$ac_cv_lib_'$ac_lib_var`\" = yes" ; then
+  echo "$ac_t""yes" 1>&6
+  with_database_berkdb=yes need_libdb=yes
+else
+  echo "$ac_t""no" 1>&6
+fi
+
+
+fi
+
+
+fi
+
+fi
+
+
   if test "$with_database_berkdb" = "yes"; then
     for path in "db/db.h" "db.h"; do
 cat > conftest.$ac_ext <<EOF
-#line 10868 "configure"
+#line 10949 "configure"
 #include "confdefs.h"
 #ifdef HAVE_INTTYPES_H
 #define __BIT_TYPES_DEFINED__
 
 ; return 0; }
 EOF
-if { (eval echo configure:10886: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
+if { (eval echo configure:10967: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; }; then
   rm -rf conftest*
   db_h_path="$path"; break
 else
 if test "$with_socks" = "yes"; then
   
 echo $ac_n "checking for SOCKSinit in -lsocks""... $ac_c" 1>&6
-echo "configure:10937: checking for SOCKSinit in -lsocks" >&5
+echo "configure:11018: checking for SOCKSinit in -lsocks" >&5
 ac_lib_var=`echo socks'_'SOCKSinit | sed 'y%./+-%__p_%'`
 
 xe_check_libs=" -lsocks "
 cat > conftest.$ac_ext <<EOF
-#line 10942 "configure"
+#line 11023 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
 SOCKSinit()
 ; return 0; }
 EOF
-if { (eval echo configure:10953: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:11034: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
 do
 ac_safe=`echo "$ac_hdr" | sed 'y%./+-%__p_%'`
 echo $ac_n "checking for $ac_hdr""... $ac_c" 1>&6
-echo "configure:11010: checking for $ac_hdr" >&5
-
-cat > conftest.$ac_ext <<EOF
-#line 11013 "configure"
+echo "configure:11091: checking for $ac_hdr" >&5
+
+cat > conftest.$ac_ext <<EOF
+#line 11094 "configure"
 #include "confdefs.h"
 #include <$ac_hdr>
 EOF
 ac_try="$ac_cpp conftest.$ac_ext >/dev/null 2>conftest.out"
-{ (eval echo configure:11018: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
+{ (eval echo configure:11099: \"$ac_try\") 1>&5; (eval $ac_try) 2>&5; }
 ac_err=`grep -v '^ *+' conftest.out`
 if test -z "$ac_err"; then
   rm -rf conftest*
 
 test -z "$with_shlib" && test ! -z "$have_dlfcn" && { 
 echo $ac_n "checking for dlopen in -ldl""... $ac_c" 1>&6
-echo "configure:11049: checking for dlopen in -ldl" >&5
+echo "configure:11130: checking for dlopen in -ldl" >&5
 ac_lib_var=`echo dl'_'dlopen | sed 'y%./+-%__p_%'`
 
 xe_check_libs=" -ldl "
 cat > conftest.$ac_ext <<EOF
-#line 11054 "configure"
+#line 11135 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
 dlopen()
 ; return 0; }
 EOF
-if { (eval echo configure:11065: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:11146: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
  }
 test -z "$with_shlib" && test ! -z "$have_dlfcn" && { 
 echo $ac_n "checking for _dlopen in -lc""... $ac_c" 1>&6
-echo "configure:11094: checking for _dlopen in -lc" >&5
+echo "configure:11175: checking for _dlopen in -lc" >&5
 ac_lib_var=`echo c'_'_dlopen | sed 'y%./+-%__p_%'`
 
 xe_check_libs=" -lc "
 cat > conftest.$ac_ext <<EOF
-#line 11099 "configure"
+#line 11180 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
 _dlopen()
 ; return 0; }
 EOF
-if { (eval echo configure:11110: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:11191: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
  }
 test -z "$with_shlib" && test ! -z "$have_dlfcn" && { 
 echo $ac_n "checking for dlopen in -lc""... $ac_c" 1>&6
-echo "configure:11139: checking for dlopen in -lc" >&5
+echo "configure:11220: checking for dlopen in -lc" >&5
 ac_lib_var=`echo c'_'dlopen | sed 'y%./+-%__p_%'`
 
 xe_check_libs=" -lc "
 cat > conftest.$ac_ext <<EOF
-#line 11144 "configure"
+#line 11225 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
 dlopen()
 ; return 0; }
 EOF
-if { (eval echo configure:11155: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:11236: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
  }
 test -z "$with_shlib" && { 
 echo $ac_n "checking for shl_load in -ldld""... $ac_c" 1>&6
-echo "configure:11184: checking for shl_load in -ldld" >&5
+echo "configure:11265: checking for shl_load in -ldld" >&5
 ac_lib_var=`echo dld'_'shl_load | sed 'y%./+-%__p_%'`
 
 xe_check_libs=" -ldld "
 cat > conftest.$ac_ext <<EOF
-#line 11189 "configure"
+#line 11270 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
 shl_load()
 ; return 0; }
 EOF
-if { (eval echo configure:11200: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:11281: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
  }
 test -z "$with_shlib" && { 
 echo $ac_n "checking for dld_init in -ldld""... $ac_c" 1>&6
-echo "configure:11229: checking for dld_init in -ldld" >&5
+echo "configure:11310: checking for dld_init in -ldld" >&5
 ac_lib_var=`echo dld'_'dld_init | sed 'y%./+-%__p_%'`
 
 xe_check_libs=" -ldld "
 cat > conftest.$ac_ext <<EOF
-#line 11234 "configure"
+#line 11315 "configure"
 #include "confdefs.h"
 /* Override any gcc2 internal prototype to avoid an error.  */
 /* We use char because int might match the return type of a gcc2
 dld_init()
 ; return 0; }
 EOF
-if { (eval echo configure:11245: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:11326: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_lib_$ac_lib_var=yes"
 else
 dll_oflags="-o "
 
 echo $ac_n "checking how to build a shared library""... $ac_c" 1>&6
-echo "configure:11295: checking how to build a shared library" >&5
+echo "configure:11376: checking how to build a shared library" >&5
 case `uname -rs` in
 	UNIX_SV*|UNIX_System_V*)
 		dll_lflags="-G"
   for ac_func in dlerror
 do
 echo $ac_n "checking for $ac_func""... $ac_c" 1>&6
-echo "configure:11386: checking for $ac_func" >&5
-
-cat > conftest.$ac_ext <<EOF
-#line 11389 "configure"
+echo "configure:11467: checking for $ac_func" >&5
+
+cat > conftest.$ac_ext <<EOF
+#line 11470 "configure"
 #include "confdefs.h"
 /* System header to define __stub macros and hopefully few prototypes,
     which can conflict with char $ac_func(); below.  */
 
 ; return 0; }
 EOF
-if { (eval echo configure:11412: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
+if { (eval echo configure:11493: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest; then
   rm -rf conftest*
   eval "ac_cv_func_$ac_func=yes"
 else
 fi
 
 cat > conftest.$ac_ext <<EOF
-#line 11448 "configure"
+#line 11529 "configure"
 #include "confdefs.h"
 int main(int c,char *v[]){return 0;}
 EOF
-if { (eval echo configure:11452: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest && (./conftest; exit) 2>&5
+if { (eval echo configure:11533: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest && (./conftest; exit) 2>&5
 then
   :
 else
 fi
 
 if test "$with_database_berkdb" != "no"; then
-  AC_CHECK_FUNC(dbopen, with_database_berkdb=yes need_libdb=no)
-  if test "$need_libdb" != "no"; then
-    AC_CHECK_LIB(db, dbopen, with_database_berkdb=yes need_libdb=yes)
-    fi
+  AC_CHECK_FUNC(dbopen,     with_database_berkdb=yes need_libdb=no,
+  AC_CHECK_FUNC(db_open,    with_database_berkdb=yes need_libdb=no,
+  AC_CHECK_LIB(db, dbopen,  with_database_berkdb=yes need_libdb=yes,
+  AC_CHECK_LIB(db, db_open, with_database_berkdb=yes need_libdb=yes))))
+
   if test "$with_database_berkdb" = "yes"; then
     for path in "db/db.h" "db.h"; do
 AC_TRY_COMPILE([#ifdef HAVE_INTTYPES_H
 M-x cd to the appropriate directory, and issue the command `C-u M-!' from
 within XEmacs.
 
-* XEmacs 21 packages
-
-XEmacs 21 has added the concept of installable packages searched prior
-to dump time when building.
-
-Packages are searched by default under /usr/local/lib/xemacs/packages/.
-The summary message in configure will tell you where XEmacs is looking 
-for them.  The packages hierarchy differs from site-lisp in that you
-do not have to install XEmacs to use it.  Indeed, the package path is
-searched prior to dump time so that installed packages have the same
-status as lisp distributed in the xemacs core tarball.
-
-The structure of each directory in the package search path should look
-like the base installed directory (ie. have etc/, info/, and lisp/,).
-Lisp is searched recursively.  It and all subdirectories are added to
-the `load-path'.  Each etc directory is added to `data-directory-list',
-and each info directory is added to `Info-default-directory-list'.
-
-A `find . -type d -print' in my top-level package directory reveals:
-./etc
-./etc/auctex
-./etc/auctex/style
-./etc/gnus
-./etc/skk
-./etc/gnusrefcard
-./etc/smilies
-./etc/message
-./info
-./lisp
-./lisp/gnus
-./lisp/auctex
-./lisp/auctex/man
-./lisp/footnote
-./lisp/skk
-
-
-AUCTeX and Gnus have package tarballs in
-	ftp://ftp.xemacs.org/pub/xemacs/beta/xemacs-21.0/packages/
-that you can simply untar in a package directory to install.
-
 ** Packages directory on the FTP Site
 =====================================
 
     lisp with.
 
 **** Grab a mule-base tarball and install it into a newly created package
-      directory.
+     directory.
 
 **** Configure XEmacs with mule and a package-path including the
      directory created above.
 **** Do a make from the top level package lisp source directory.[1]
 
 **** Do `make bindist's on all the packages you wish to install and
-  remove the byproduct .tar.gz's.
+     remove the byproduct .tar.gz's.
 
-*** Phase 3 -- Redump XEmacs with the packages that require dump time
-    support (like egg-its, VM, etc.) and install it.
+*** Phase 3 -- If necessary, redump XEmacs
+    with the packages that require dump-time support and install it.
 
 **** Reconfigure without Mule if you don't wish a Mule-ish XEmacs, and
      rebuild XEmacs.
-						-*- mode:outline -*-
-* Introduction to XEmacs Packages
-=================================
-
-As of XEmacs 21.0, XEmacs is no longer distributed in a large
-monolithic distribution.  The distribution has been broken up into
-separate units called packages.  In the general case, one may install
-and uninstall various packages freely without having to modify the
-XEmacs binary.  This gives an installer the ability to tailor an
-XEmacs installation for local needs with safe removal of unnecessary
-code.
-
-There are two main flavors of packages.
-
-** Regular Packages
-===================
-
-A regular package is one in which multiple files are involved and one
-may not in general safely remove any of them.
-
-** Single-File Packages
-=======================
-
-A single-file package is an aggregate collection of thematically
-related but otherwise independent lisp files.  These files are bundled 
-together for download convenience and individual files may deleted at
-will without any loss of functionality.
-
-* Package mechanics
-===================
-
-This section describes how package hierarchy directories are put
-together and how they may be configured into XEmacs.
-
-** Package Path
-===============
-
-For backwards compatibility and for ease of transition to XEmacs 21, it
-is possible to use previous XEmacs installations as package directories.
-Specify something like
---package-path="~/.xemacs::/somewhere-newpackages::/usr/local/lib/xemacs-20.4"
-to configure when building.  You will have extra messages at dump
-time relating to lisp shadows which you may ignore.  The first
-magical null directory `::' is a marker indicating what packages
-should only be searched at run-time.  The second magical null
-directory is used to indicate where Lisp bundled with the running
-XEmacs gets put at the back of load path.  By specifing the older
-directories after the current one, the newer lisp overrides the
-older lisp.
-
-** The anatomy of an XEmacs Package hierarchy
-=============================================
-
-An XEmacs package is laid out just like a normal installed XEmacs lisp
-directory.  It may have lisp, etc, info, and lib-src subdirectories.
-These directories get added at XEmacs startup to whatever directories
-it was already using.
-
-There may be any number of Package hierarchy directories.
-
-* Package Distributions
-=======================
-
-XEmacs lisp packages are distributed in two ways depending on the
-intended use.  Binary Packages are for installers and end-users and
-may be installed directly into an XEmacs package directory.  Source
-Packages are for developers and include all files necessary for
-rebuilding bytecompiled lisp and creating tarballs for distribution.
-
-** Binary Packages
-==================
-
-Binary packages may be installed directly into an XEmacs package
-directory.  XEmacs package directories are determined at the time
-XEmacs is configured for building.  The default is
-${prefix}/lib/xemacs/packages.  `prefix' defaults to /usr/local unless 
-changed by the XEmacs configurer.  This may be changed by specifying a 
-path of the form --package-path=directory:directory:directory... (all
-directories separated by colons).  There is no restriction on the
-number of directories.  There may be no package directories, but
-XEmacs won't be very useful.
-
-** Source Packages
-==================
-
-Source packages contain all of the Package author's (where appropriate
-in regular packages) source code plus all of the files necessary to
-build distribution tarballs (Unix Tar format files and gzipped for
-space savings).
-
-*** Prerequisites for building Source Packages
-
-You must have GNU cp, GNU ginstall (or a BSD compatible install
-program) GNU make (3.75 or later preferred), makeinfo (1.68 from
-texinfo-3.11 or later required), GNU tar and XEmacs 21.0 :-).  The
-source packages will untar into a correct directory structure.  At
-the top level you must have XEmacs.rules and package-compile.el.
-These files are available from the XEmacs FTP site from the same
-place you obtained your source package distributions.
-
-*** What you can do with Source Packages
-
-NB:  A global build operation doesn't exist yet as of 13 January 1998.
-
-Source packages are most useful for creating XEmacs package tarballs
-for installation into your own XEmacs installations or for
-distributing to others.
-
-Supported operations from Make are:
-
-**** clean
-
-Remove all built files except auto-autoloads.el and custom-load.el.
-
-**** distclean
-
-Remove XEmacs backups as well as the files deleted by `make clean'.
-
-**** all
-
-Byte compile all files, build and bytecompile byproduct files like
-auto-autoloads.el and custom-load.el.  Create info version of TeXinfo
-documentation if present.
-
-**** srckit
-
-Usually aliased to `make srckit-std'.  This does a `make distclean'
-and creates a Package source tarball in the staging directory.  This
-is generally only of use for package maintainers.
-
-**** binkit
-
-May be aliased to binkit-sourceonly, binkit-sourceinfo,
-binkit-sourcedata, or binkit-sourcedatainfo. `sourceonly' indicates
-there is nothing to install in a data directory or info directory.
-`sourceinfo' indicates that source and info files are to be
-installed.  `sourcedata' indicates that source and etc (data) files
-are to be installed.  `sourcedatainfo' indicates source, etc (data),
-and info files are to be installed.  A few packages have needs beyond
-the basic templates so this is not yet complete.
-
-**** dist
-
-Runs the rules `srckit' followed by `binkit'.  This is primarily of
-use by XEmacs maintainers producing files for distribution.
-
 * Description of available packages by category
 ===============================================
 
 
 A Lisp debugger.
 
+*** dired
+
+The DIRectory EDitor is for manipulating, and running commands on
+files in a directory.
+
 *** efs
 
-Treat files on remote systems the same as local files.  Also contains
-dired.
+Treat files on remote systems the same as local files.
 
 *** mail-lib
 
+1998-06-20  Michael Sperber [Mr. Preprocessor]  <sperber@informatik.uni-tuebingen.de>
+
+	* xemacs/abbrevs.texi: 
+	* xemacs/basic.texi: 
+	* xemacs/buildings.texi: 
+	* xemacs/cmdargs.texi: 
+	* xemacs/files.texi: 
+	* xemacs/adjustments.texi: Adjustments to integrate startup.texi
+	and packages.texi stuff.
+
+	* xemacs/startup.texi: 
+	* xemacs/packages.texi: Created.
+
 1998-06-10  Adrian Aichner  <aichner@ecf.teradyne.com>
 
 	* texinfo.texi: added ../info/ to @setfilename, broke line after

man/xemacs/abbrevs.texi

 
-@node Abbrevs, Picture, Running, Top
+@node Abbrevs, Picture, Packages, Top
 @chapter Abbrevs
 @cindex abbrevs
 @cindex expansion (of abbrevs)

man/xemacs/basic.texi

 
-@node Basic, Undo, Command Switches, Top
+@node Basic, Undo, Startup Paths, Top
 @chapter Basic Editing Commands
 
 @kindex C-h t

man/xemacs/building.texi

 
-@node Running, Abbrevs, Programs, Top
+@node Running, Packages, Programs, Top
 @chapter Compiling and Testing Programs
 
   The previous chapter discusses the Emacs commands that are useful for

man/xemacs/cmdargs.texi

 
-@node Command Switches, Basic, Exiting, Top
+@node Command Switches, Startup Paths, Exiting, Top
 @section Command Line Switches and Arguments
 @cindex command line arguments
 @cindex arguments (from shell)
 Exit from Emacs without asking for confirmation.
 
 @item -version
+@itemx -V
 Prints version information.  This implies @samp{-batch}.
 
 @example
 @item -debug-init
 Enter the debugger if an error in the init file occurs.
 
+@item -debug-paths
+Displays information on how XEmacs constructs the various paths into its
+hierarchy on startup.  (See also @pxref{Startup Paths}.)
+
 @item -unmapped
 Do not map the initial frame.  This is useful if you want to start up
 XEmacs as a server (e.g. for gnuserv screens or external client widgets).
 @item -no-site-file
 Do not load the site-specific init file @file{lisp/site-start.el}.
 
+@item -no-autoloads
+Do not load global symbol files (@file{auto-autoloads}) at startup.
+This implies @samp{-vanilla}. 
+
+@item -no-early-packages
+Do not process early packages.  (For more information on startup issues
+concerning the package system, @xref{Startup Paths}.)
+
+@item -vanilla
+This is equivalent to @samp{-q -no-site-file -no-early-packages}.
+
 @item -user @var{user}
 @itemx -u @var{user}
 Load @var{user}'s Emacs init file @file{~@var{user}/.emacs} instead of
 your own.
+
+
 @end table
 
 @vindex command-line-args

man/xemacs/files.texi

 requested.
 
 @table @kbd
-@item c
+@item C
 Copies the file described on the current line.  You must supply a file name
 to copy to, using the minibuffer.
 @item f
 Like @kbd{f}, but uses another window to display the file's buffer.  The
 Dired buffer remains visible in the first window.  This is like using
 @kbd{C-x 4 C-f} to visit the file.  @xref{Windows}.
-@item r
+@item R
 Renames the file described on the current line.  You must supply a file
 name to rename to, using the minibuffer.
 @item v

man/xemacs/packages.texi

+@node Packages, Abbrevs, Running, Top
+@comment  node-name,  next,  previous,  up
+
+@section Introduction to XEmacs Packages
+@cindex packages
+
+The XEmacs 21 distribution comes only with a very basic set of
+built-in modes and packages.  Most of the packages that were part of
+the distribution of earlier versions of XEmacs are now separately
+available.  The installer as well as the user can choose which
+packages to install; the actual installation process is easy.
+This gives an installer the ability to tailor an XEmacs installation for
+local needs with safe removal of unnecessary code.
+
+@subsection Package Flavors
+
+There are two main flavors of packages.
+
+@itemize @emph
+@item Regular Packages
+A regular package is one in which multiple files are involved and one
+may not in general safely remove any of them.
+
+@item Single-File Packages
+A single-file package is an aggregate collection of thematically
+related but otherwise independent lisp files.  These files are bundled 
+together for download convenience and individual files may deleted at
+will without any loss of functionality.
+@end itemize
+
+@subsection Package Distributions
+
+XEmacs Lisp packages are distributed in two ways depending on the
+intended use.  Binary Packages are for installers and end-users and may
+be installed directly into an XEmacs package directory.  Source Packages
+are for developers and include all files necessary for rebuilding
+bytecompiled lisp and creating tarballs for distribution.
+
+@subsection Binary Packages
+Binary packages may be installed directly into an XEmacs package
+hierarchy.
+
+@subsection Source Packages
+
+Source packages contain all of the Package author's (where appropriate
+in regular packages) source code plus all of the files necessary to
+build distribution tarballs (Unix Tar format files and gzipped for space
+savings).
+
+@subsection Prerequisites for building Source Packages
+
+You must have GNU @code{cp}, GNU @code{install} (or a BSD compatible
+@code{install} program) GNU @code{make} (3.75 or later preferred),
+@code{makeinfo} (1.68 from @code{texinfo-3.11} or later required), GNU
+@code{tar} and XEmacs 21.0.  The source packages will untar into a
+correct directory structure.  At the top level you must have
+@file{XEmacs.rules} and @file{package-compile.el}.  These files are
+available from the XEmacs FTP site from the same place you obtained your
+source package distributions.
+
+@subsection What you can do with Source Packages
+
+NB:  A global build operation doesn't exist yet as of 13 January 1998.
+
+Source packages are most useful for creating XEmacs package tarballs
+for installation into your own XEmacs installations or for
+distributing to others.
+
+Supported operations from Make are:
+
+@table @code
+@item clean
+Remove all built files except @file{auto-autoloads.el} and @file{custom-load.el}.
+
+@item distclean
+Remove XEmacs backups as well as the files deleted by @code{make clean}.
+
+@item all
+Bytecompile all files, build and bytecompile byproduct files like
+@file{auto-autoloads.el} and @file{custom-load.el}.  Create info version
+of TeXinfo documentation if present.
+
+@item srckit
+Usually aliased to @code{make srckit-std}.  This does a @code{make
+distclean} and creates a package source tarball in the staging
+directory.  This is generally only of use for package maintainers.
+
+@item binkit
+May be aliased to @code{binkit-sourceonly}, @code{binkit-sourceinfo},
+@code{binkit-sourcedata}, or
+@code{binkit-sourcedatainfo}. @code{sourceonly} indicates there is
+nothing to install in a data directory or info directory.
+@code{sourceinfo} indicates that source and info files are to be
+installed.  @code{sourcedata} indicates that source and etc (data) files
+are to be installed.  @code{sourcedatainfo} indicates source, etc
+(data), and info files are to be installed.  A few packages have needs
+beyond the basic templates so this is not yet complete.
+
+@item dist
+Runs the rules @code{srckit} followed by @code{binkit}.  This is
+primarily of use by XEmacs maintainers producing files for distribution.
+
+@end table

man/xemacs/startup.texi

+@node Startup Paths, Basic, Command Switches, Top
+@comment  node-name,  next,  previous,  up
+@section How XEmacs finds Directories and Files
+
+@cindex startup paths
+@cindex directories
+
+XEmacs deals with a multitude of files during operation.  These files
+are spread over many directories, and XEmacs determines the location of
+most of these directories at startup and organizes them into various
+paths.  (A @emph{path},
+@cindex path
+for the purposes of this section, is simply a list of directories which
+XEmacs searches successively in order to locate a file.)
+
+@subsection XEmacs Directory Hierarchies
+@cindex hierarchies
+@cindex directory hierarchies
+
+Many of the files XEmacs looks for are located within the XEmacs
+installation itself.  However, there are several views of what actually
+constitutes the "XEmacs installation": XEmacs may be run from the
+compilation directory, it may be installed into arbitrary directories,
+spread over several directories unrelated to each other.  Moreover, it
+may subsequently moved to a different place.  (This last case is not as
+uncommon as it sounds.  Binary kits work this way.)  Consequently,
+XEmacs has quite complex procedures in place to find directories, no
+matter where they may be hidden.
+
+XEmacs will always respect directory options passed to @code{configure}.
+However, if it cannot locate a directory at the configured place, it
+will initiate a search for the directory in any of a number of
+@emph{hierachies} rooted under a directory which XEmacs assumes contain
+parts of the XEmacs installation; it may locate several such hierarchies
+and search across them.  (Typically, there are just one or two
+hierarchies: the hierarchy where XEmacs was or will be installed, and
+the one where it is being built.)  Such a directory containing a
+hierarchy is called a @emph{root}.
+@cindex root of a hierarchy
+Whenever this section refers to a directory using the shorthand
+@code{<root>}, it means that XEmacs searches for it under all
+hierarchies under all hierarchies XEmacs was able to scrounge up.  In a
+running XEmacs, the hierarchy roots are stored in the variable
+@code{emacs-roots}.
+@vindex emacs-roots
+
+@subsection Package Hierarchies
+@cindex package hierarchies
+
+Many relevant directories and files XEmacs uses are actually not part of
+the core installation.  They are part of any of the many packages
+usually installed on top of an XEmacs installation.  (@xref{Packages}.)
+Hence, they play a prominent role in the various paths XEmacs sets up.
+
+XEmacs locates packages in any of a number of package hierarchies.
+Package hierarchies fall into three groups: @emph{early}, @emph{late},
+and @emph{last},
+@cindex early package hierarchies
+@cindex late package hierarchies
+@cindex last package hierarchies
+according to the relative location at which they show
+up in the various XEmacs paths.  Early package hierarchies are at the
+very front, late ones somewhere in the middle, and last hierarchies are
+(you guessed it) last.
+
+By default, XEmacs expects an early package hierarchy in the a
+subdirectory @file{.xemacs} of the user's home directory.
+
+Moreover, XEmacs expects late hierarchies in the subdirectories
+@file{site-packages}, @file{mule-packages}, and @file{xemacs-packages}
+(in that order) of the @file{<root>/lib/xemacs} subdirectory of one of
+the installation hierarchies.  (If you run in-place, these are directr
+subdirectories of the build directory.)  Furthermore, XEmacs will also
+search these subdirectories in the @file{<root>/lib/xemacs-<VERSION>}
+subdirectory and prefer directories found there.
+
+By default, XEmacs does not have a pre-configured last package
+hierarchy.  Last hierarchies are primarily for using package
+hierarchies of outdated versions of XEmacs as a fallback option.  For
+example, it is possible to run XEmacs with the 20.4 package hierarchy
+as a last hierarchy.
+
+It is possible to specify at configure-time the location of the various
+package hierarchies with the @code{--package-path} option to configure.
+@cindex package path
+The early, late, and last components of the package path are separated
+by double instead of single colons.  If three components are present,
+they are locate the early, late, and last package hierarchies
+respectively.  If two components are present, they locate the early and
+late hierarchies.  If only one component is present, it locates the late
+hierarchy.  At run time, the package path may also be specified via the
+@code{PACKAGEPATH} environment variable.
+
+An XEmacs package is laid out just like a normal installed XEmacs lisp
+directory.  It may have @file{lisp}, @file{etc}, @file{info}, and
+@file{lib-src} subdirectories.  XEmacs adds these at appropriate places
+within the various system-wide paths.
+
+There may be any number of package hierarchy directories.
+
+@subsection Directories and Paths
+@cindex paths
+
+Here is a list of the various directories and paths XEmacs tries to
+locate during startup.  XEmacs distinguishes between directories and
+paths specific to @emph{version}, @emph{site}, and @emph{architecture}
+when looking for them.
+
+@table @code
+@item version-specific
+directories are specific to the version of XEmacs they belong to and
+typically reside under @file{<root>/lib/xemacs-<VERSION>}.
+@item site-specific
+directories are independent of the version of XEmacs they belong to and
+typically reside under @file{<root>/lib/xemacs}
+@item architecture-specific
+directories are specific both to the version of XEmacs and the
+architecture it runs on and typically reside under
+@file{<root>/lib/xemacs-<VERSION>/<ARCHITECTURE>}.
+@end table
+
+During installation, all of these directories may also reside directly
+under @file{<root>}, because that is where they are in the XEmacs tarball.
+
+If XEmacs runs with the @code{-debug-paths} option (@xref{Command
+Switches}), it will print the values of these variables, hopefully
+aiding in debugging any problems which come up.
+
+@table @code
+
+@item lisp-directory
+@vindex lisp-directory
+Contains the version-specific location of the Lisp files that come with
+the core distribution of XEmacs.  XEmacs will search it recursively to a
+depth of 1 when setting up @code{load-path}.
+
+@item load-path
+@vindex load-path
+Is where XEmacs searches for XEmacs Lisp files with commands like
+@code{load-library}.
+@findex load-library
+It contains the package lisp directories (see further down) and the
+version-specific core Lisp directories.  If the environment variable
+@code{EMACSLOADPATH} is set at startup, its directories are prepended to
+@code{load-path}.
+@vindex EMACSLOADPATH
+
+@item Info-directory-list
+@vindex Info-directory-list
+Contains the location of info files.  (See @ref{(info)}.)  It contains
+the package info directories and the version-specific core
+documentation.  Moreover, XEmacs will add @file{/usr/info},
+@file{/usr/local/info} as well as the directories of the environment
+variable @code{INFOPATH}
+@vindex INFOPATH
+to @code{Info-directory-list}.
+
+@item lock-directory
+@itemx superlock-file
+@vindex lock-directory
+@vindex superlock-file
+Are the site-specific locations of the lock directory and the superlock
+file, respectively.  The @code{lock-directory} variable may also be
+initialized from the @code{EMACSLOCKDIR}
+@vindex EMACSLOCKDIR
+environment variable.
+
+@item exec-directory
+@vindex exec-directory
+Is the directory of architecture-dependent files that come with XEmacs,
+especially executable programs intended for XEmacs to invoke.
+
+@item exec-path
+@vindex exec-path
+Is the path for executables which XEmacs may want to start.  It contains
+the package executable paths as well as @code{exec-directory}, and the
+directories of the environment variables @code{PATH}
+@vindex PATH
+and @code{EMACSPATH}.
+@vindex EMCSPATH
+
+@item doc-directory
+@vindex doc-directory
+Is the directory containing the architecture-specific @file{DOC} file
+that contains documentation for XEmacs' commands.
+
+@item data-directory
+@vindex data-directory
+Is the version-specific directory that contains core data files XEmacs uses.
+It may be initialized from the @code{EMACSDATA}
+@vindex EMACSDATA
+environment variable.
+
+@item data-directory-list
+@vindex data-directory-list
+Is the path where XEmacs looks for data files.  It contains package data
+directories as well as @code{data-directory}.
+
+@end table
+
+

man/xemacs/xemacs.texi

 * Exiting::     Stopping or killing XEmacs.
 * Command Switches::  
                 Hairy startup options.
+* Startup Paths::
+                How XEmacs finds Directories and Files
 
 Fundamental Editing Commands
 * Basic::       The most basic editing commands.
 * Text::        Commands and modes for editing English.
 * Programs::    Commands and modes for editing programs.
 * Running::     Compiling, running and debugging programs.
+* Packages::    How to add new packages to XEmacs.
 * Abbrevs::     How to define text abbreviations to reduce
                  the number of characters you must type.
 * Picture::     Editing pictures made up of characters
 * Compiling Libraries:: Compiling a library makes it load and run faster.
 * Mocklisp::		Converting Mocklisp to Lisp so XEmacs can run it.
 
+Packages
+* Packages::            Introduction to XEmacs Packages.
+
 Abbrevs
 
 * Defining Abbrevs::  Defining an abbrev, so it will expand when typed.
 @include menus.texi
 @include entering.texi
 @include cmdargs.texi
+@include startup.texi
 @include basic.texi
 @include undo.texi
 @include mini.texi
 @include text.texi
 @include programs.texi
 @include building.texi
+@include packages.texi
 @include abbrevs.texi
 @include picture.texi
 @include sending.texi
+1998-06-21  Olivier Galibert  <galibert@pobox.com>
+
+	* lisp-disunion.h (XMARKBIT): Have XMARKBIT return something
+	suitable for an int used as a boolean (btw, C sucks.).
+
+1998-06-18  Andy Piper  <andyp@parallax.co.uk>
+
+	* object-msw.c: remove warnings.
+
+	* device-msw.c: #define wrongly named cygwin structure elements.
+
+	* s/cygwin32.h: define DEMI_BOLD
+
 1998-06-19  Jonathan Harris  <jhar@tardis.ed.ac.uk>
 
 	* redisplay-msw.c: new function mswindows_apply_face_effects.
-/* Device functions for mswindows.
+/* device functions for mswindows.
    Copyright (C) 1994, 1995 Board of Trustees, University of Illinois.
    Copyright (C) 1994, 1995 Free Software Foundation, Inc.
 
 
 #ifndef __CYGWIN32__
 #include <commctrl.h>
+#else
+#define FONTENUMPROC FONTENUMEXPROC
+#define ntmTm ntmentm
 #endif
 
 /* win32 DDE management library globals */
   struct device *d;
 };
 
-
+
 /************************************************************************/
 /*                               helpers                                */
 /************************************************************************/

src/lisp-disunion.h

 #else /* !USE_MINIMAL_TAGBITS */
 
 # define MARKBIT (1UL << VALBITS)
-# define XMARKBIT(x) ((x) & MARKBIT)
+# define XMARKBIT(x) (((x) & MARKBIT) != 0)
 # define XMARK(x) ((void) ((x) |= MARKBIT))
 # define XUNMARK(x) ((void) ((x) &= ~MARKBIT))
 # define make_obj(vartype, value) \

src/objects-msw.c

 static int
 match_font (char *pattern1, char *pattern2, char *fontname)
 {
-  char *c1=pattern1, *c2=pattern2, *e1, *e2;
+  char *c1=pattern1, *c2=pattern2, *e1=0, *e2=0;
   int i;
 
   if (fontname)
-/* System description file for cygwin32.
+/* system description file for cygwin32.
    Copyright (C) 1993, 1994, 1995 Free Software Foundation, Inc.
 
 This file is part of GNU Emacs.
 #define SIF_TRACKPOS	0x0010
 #define FW_BLACK	FW_HEAVY
 #define FW_ULTRABOLD	FW_EXTRABOLD
+#define FW_DEMIBOLD	FW_SEMIBOLD
 #define FW_ULTRALIGHT	FW_EXTRALIGHT
 #define VK_APPS			0x5D
 #define APPCMD_FILTERINITS	0x20L
 #define HEAP_IN_DATA
 #define UNEXEC "unexcw.o"
 /* #define BROKEN_SIGIO */
-#define PROCESS_IO_BLOCKING 
+#define PROCESS_IO_BLOCKING
 #define strnicmp strncasecmp
 #ifndef HAVE_SOCKETS
 #define HAVE_SOCKETS
 emacs_major_version=21
 emacs_minor_version=0
 emacs_beta_version=
-xemacs_codename="Thuringian"
+xemacs_codename="Toggenburg"
 infodock_major_version=3
 infodock_minor_version=90
 infodock_build_version=10
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.