6 You are running a potentially unstable version of XEmacs. Please do
7 not report problems with Beta XEmacs to comp.emacs.xemacs. Report
8 them to xemacs-beta@xemacs.org.
13 *** XEmacs Beta Mailing List
14 ----------------------------
16 If you are not subscribed to the XEmacs beta list you should be.
17 Currently all discussion of development issues, including bug reports
18 and coding discussion, takes place on the XEmacs Beta mailing list.
19 Only patches and administrative actions regarding patches are sent
20 elsewhere (to the XEmacs Patches list).
22 ** XEmacs Patches Mailing List
23 ==============================
25 XEmacs Patches records proposed changes to XEmacs, and their
26 disposition. It is open subscription, but only patches and actions by
27 members of the XEmacs Review Board should be posted to this list. You
28 can follow progress of your patch by subscribing to the mailing list
34 In the descriptions below, the word LIST (all uppercase) is a
35 variable. Substitute "beta" or "patches" as appropriate (to get
36 "xemacs-beta" as the mailbox for the XEmacs Beta mailing list, or
37 http://www.xemacs.org/Lists/#xemacs-beta for its URL).
39 The XEmacs mailing lists are managed by the Mailman mailing list
40 package, and the usual Mailman commands work. Do not send mailing
41 list requests to the main address (xemacs-LIST@xemacs.org), always
42 send them to xemacs-LIST-request@xemacs.org. If you have problems
43 with the list itself, they should be brought to the attention of the
44 XEmacs Mailing List manager <list-manager@xemacs.org> (the same
45 mailbox, "list-manager", for all lists). All public mailing lists
46 have searchable archives. The URL is
48 http://list-archive.xemacs.org/xemacs-LIST
50 *** Managing your subscription via the Web
51 ------------------------------------------
53 Subscription, unsubscription, and options (such as digests and
54 temporarily suspending delivery) can be accomplished via the web
55 interface at http://www.xemacs.org/Lists/#xemacs-LIST.
57 *** Subscribing by e-mail
58 -------------------------
60 Send an email message to xemacs-LIST-request@xemacs.org with
61 `subscribe' (without the quotes) as the BODY of the message.
63 *** Unsubscribing by e-mail
64 ---------------------------
66 Send an email message to xemacs-LIST-request@xemacs.org with
67 `unsubscribe' (without the quotes) as the BODY of the message.
69 ** Beta Release Schedule
70 ========================
72 Betas are now released rather sporadically. We would like to achieve
73 a weekly release schedule, but personnel availability does not
74 permit. For access to the most recent code, use CVS (see
75 http://www.xemacs.org/Develop/cvsaccess.html for more information).
76 If you have need for FTP access, please let us know. It will make it
77 more likely that we release betas more often.
82 The best way to get problems fixed in XEmacs is to submit good problem
83 reports. Since this is beta software, problems are certain to exist.
84 Please read through all of part II of the XEmacs FAQ for an overview
85 of problem reporting. Other items which are most important are:
87 1. Do not submit C stack backtraces without line numbers. Since it
88 is possible to compile optimized with debug information with GCC
89 it is never a good idea to compile XEmacs without the -g flag.
90 XEmacs runs on a variety of platforms, and often it is not
91 possible to recreate problems which afflict a specific platform.
92 The line numbers in the C stack backtrace help isolate where the
93 problem is actually occurring.
95 2. Attempt to recreate the problem starting with an invocation of
96 XEmacs with `xemacs -q -no-site-file -no-autoloads'. Quite often,
97 problems are due to package interdependencies, and the like. An
98 actual bug in XEmacs should be reproducible in a default
99 configuration without loading any special packages (or the one or
100 two specific packages that cause the bug to appear). If you have
101 trouble getting anything to work at all with the above invocation,
102 use `xemacs -q -no-site-file' instead. If you need to load your
103 user init file or the site file to get the problem to occur, then
104 it has something to do with them, and you should try to isolate
105 the issue in those files.
107 3. A picture can be worth a thousand words. When reporting an
108 unusual display, it is generally best to capture the problem in a
109 screen dump and include that with the problem report. The easiest
110 way to get a screen dump is to use the xv program and its grab
111 function. Save the image as a GIF to keep bandwidth requirements
112 down without loss of information. MIME is the preferred method
113 for making the image attachments.
115 ** Getting the Source
116 =====================
118 In addition to the normal tar distribution, XEmacs source is now
119 available via CVS. Please see
121 http://www.xemacs.org/Develop/cvsaccess.html
123 * Compiling Beta XEmacs
124 =======================
126 ** Building an XEmacs from patches
127 ==================================
129 All beta releases of XEmacs are included with patches from the
130 previous version in an attempt to keep bandwidth requirements down.
131 Patches should be applied with the GNU patch program in something like
132 the following. Let's say you're upgrading XEmacs 20.15-beta10 to
133 XEmacs 20.15-beta11 and you have a full unmodified XEmacs 20.15-beta10
134 source tree to work with. Cd to the top level directory and issue the
137 $ gunzip -c /tmp/xemacs-20.15-b10-20.15-b11.patch.gz | patch -p1
139 After patching, check to see that no patches were missed by doing
140 $ find . -name \*.rej -print
142 Any rejections should be treated as serious problems to be resolved
143 before building XEmacs.
145 After seeing that there were no rejections, issue the commands
147 $ ./config.status --recheck
150 and go play minesweep for a while on an older XEmacs while the binary
153 ** Building XEmacs from a full distribution
154 ==============================================
156 Locate a convenient place where you have at least 100MB of free space
157 and issue the command
159 $ gunzip -c /tmp/xemacs-20.15-b11.tar.gz | tar xvf -
161 (or simply `tar zxvf /tmp/xemacs-20.15-b11.tar.gz' if you use GNU tar).
163 cd to the top level directory and issue an appropriate configure
164 command. One maintainer uses the following at the time of this
168 --cflags="-mpentium -march=pentium -O6 -g -fno-peep-spills" \
169 --error-checking=all --debug=yes \
170 --with-scrollbars=athena3d --with-dialogs=athena3d \
171 --with-mule --with-xfs --with-xim=xlib
173 Part of the configure output is a summary that looks something like
174 the following. (In XEmacs 21.1 and later, this summary is also
175 available as the file Installation in the top directory of your build
176 tree, and via the command M-x describe-installation.)
178 uname -a: Linux altair.xemacs.org 2.0.32 #2 Sun Nov 16 18:52:14 PST 1997 i586
180 ./configure '--cflags=-mpentium -march=pentium -O6 -g -fno-peep-spills' '--error-checking=all' '--debug=yes' '--with-scrollbars=athena3d' '--with-dialogs=athena3d' '--with-mule' '--with-xfs' '--with-xim=xlib'
183 XEmacs 21.0-b34 "Oberhasli-pre2" configured for `i586-pc-linux'.
185 Where should the build process find the source code? /home/xemacs/xemacs-20.0
186 What installation prefix should install use? /usr/local
187 What operating system and machine description files should XEmacs use?
188 `s/linux.h' and `m/intel386.h'
189 What compiler should XEmacs be built with? gcc -mpentium -march=pentium -O6 -g -fno-peep-spills
190 Should XEmacs use the GNU version of malloc? yes
191 (Using Doug Lea's new malloc from the GNU C Library.)
192 Should XEmacs use the relocating allocator for buffers? yes
193 What window system should XEmacs use? x11
194 Where do we find X Windows header files? /usr/X11/include
195 Where do we find X Windows libraries? /usr/X11/lib
196 Compiling in support for XAUTH.
197 Compiling in support for XPM images.
198 Compiling in support for X-Face message headers.
199 Compiling in support for GIF image conversion.
200 Compiling in support for JPEG image conversion.
201 Compiling in support for PNG image conversion.
202 Compiling in support for TIFF image conversion.
203 Compiling in native sound support.
204 Compiling in support for Berkeley DB.
205 Compiling in support for GNU DBM.
206 Compiling in support for ncurses.
207 Compiling in support for GPM (General Purpose Mouse).
208 Compiling in Mule (multi-lingual) support.
209 Compiling in XIM (X11R5+ I18N input method) support.
210 Using raw Xlib to provide XIM support.
211 Using XFontSet to provide bilingual menubar.
212 Compiling in support for Canna on Mule.
213 Compiling in support for the WNN input method on Mule.
215 Compiling in support for OffiX.
216 Compiling in support for proper session-management.
217 Using Lucid menubars.
218 Using Athena-3d scrollbars.
219 Using Athena-3d dialog boxes.
220 Compiling in DLL support.
221 movemail will use "dot-locking" for locking mail spool files.
222 Using Lisp_Objects with minimal tagbits.
223 Compiling in extra code for debugging.
224 Compiling in code for checking XEmacs memory usage.
225 WARNING: ---------------------------------------------------------
226 WARNING: Compiling in support for runtime error checking.
227 WARNING: XEmacs will run noticeably more slowly as a result.
228 WARNING: Error checking is on by default for XEmacs beta releases.
229 WARNING: ---------------------------------------------------------
233 Then type `make' and you should have a working XEmacs.
235 After you have verified that you have a functional editor, fire up
236 your favorite mail program and send a build report to
237 xemacs-build-reports@xemacs.org.
239 Preferrably this is done from XEmacs, following these simple steps:
241 M-x customize-group RET build-report RET
245 http://www.xemacs.org/Releases/Public-21.2/tester.html#reporting
247 If you create the report manually by other means, here is what the
248 build report should include:
250 1. Your hardware configuration (OS version, etc.)
252 2. Version numbers of software in use (X11 version, system library
253 versions if appropriate, graphics library versions if appropriate).
254 If you're on a system like Linux, include all the version numbers
255 you can because chances are it makes a difference.
257 3. The options given to configure
259 4. The configuration report illustrated above
261 For convenience all of the above items are placed in a file called
262 `Installation' in the top level build directory. They are also
263 available by performing M-x describe-installation inside XEmacs.
265 5. Any other unusual items you feel should be brought to the attention
272 ** Creating patches for submission
273 ==================================
275 Patches to XEmacs should be mailed to <xemacs-patches@xemacs.org>.
276 Each patch will be reviewed by the patches review board, and will be
277 acknowledged and added to the distribution, or rejected with an
278 explanation. Progress of the patch is tracked on the XEmacs Patches
279 mailing list, which is open subscription.
281 Patches to XEmacs Lisp packages should be sent to the maintainer of
282 the package. If the maintainer is listed as `XEmacs Development Team'
283 patches should be sent to <xemacs-patches@xemacs.org>.
285 Emailed patches should preferably be sent in MIME format and quoted
286 printable encoding (if necessary).
288 The simplest way to create well-formed patches is to use CVS and
289 Didier Verna's Patcher library (available as patcher.el in the
290 xemacs-devel package). Patcher is new and requires some setup, but
291 most of the core developers are now using it for their own patches.
292 Patcher also can be configured to create patches for several projects,
293 and recognize the project from the directory it is invoked in. This
294 makes it a useful general tool (as long as XEmacs-style patches are
295 accepted at your other projects, which is likely since they conform to
298 When making patches by hand, please use the `-u' option, or if your
299 diff doesn't support it, `-c'. Using ordinary (context-free) diffs
300 are notoriously prone to error, since line numbers tend to change when
301 others make changes to the same source file.
303 An example of the `diff' usage:
305 $ diff -u OLDFILE NEWFILE
309 $ diff -c OLDFILE NEWFILE
311 Also, it is helpful if you create the patch in the top level of the
312 XEmacs source directory:
314 $ cp -p lwlib/xlwmenu.c lwlib/xlwmenu.c.orig
316 $ diff -u lwlib/xlwmenu.c.orig lwlib/xlwmenu.c
318 Also note that if you cut & paste from an xterm to an XEmacs mail buffer
319 you will probably lose due to tab expansion. The best thing to do is
320 to use an XEmacs shell buffer to run the diff commands, or ...
321 M-x cd to the appropriate directory, and issue the command `C-u M-!' from
324 Patches should be as single-minded as possible. Mammoth patches can
325 be very difficult to place into the right slot. They are much easier
326 to deal with when broken down into functional or conceptual chunks.
327 The patches submitted by Kyle Jones and Hrvoje Niksic are stellar
328 examples of how to Do The Right Thing.
330 Each patch should be accompanied by an update to the appropriate
331 ChangeLog file. Guidelines for writing ChangeLog entries is governed
332 by the GNU coding standards. Please see
333 http://www.gnu.org/prep/standards_toc.html [Change Logs section]
336 Do not submit context diffs (either -c or -u) of ChangeLogs. Because
337 of the "stack" nature of ChangeLogs (new entries are always pushed on
338 the top), context diffs will fail to apply more often than they
339 succeed. Simply cutting and pasting the entry from an Emacs buffer to
340 the mail buffer (beware of tab expansion!) is probably easiest. The
341 Patcher library also will set up your ChangeLogs for you, and copy
342 them to the mail. Contextless unified diffs (-U 0) are also
343 acceptable but perhaps more trouble than they are worth.
345 *** Patch discussion etiquette
346 -------------------------------
348 If you intend a patch for _application_ to the sources as is, _always_
349 post it to xemacs-patches, even if there are minor points you would
350 like to have discussed by others. Not doing so will resulting in
351 patches getting "lost". If you expect that the patch will not be
352 acceptable, but are using it to stimulate discussion, then don't post
353 to xemacs-patches. Intermediate cases are up to your judgement;
354 unless you're sure you'll follow up with a "real" patch, better to err
355 on the side of posting to xemacs-patches.
357 Discussion of the _content_ of the patch (ie responses to reviewer
358 comments beyond "that's right, ok, I'll do it your way") should _always_
359 be posted to xemacs-beta. (We may split xemacs-beta into code
360 discussion and stuff that is more relevant to non-developer testers at
361 some point, but at this point xemacs-beta is the correct place for
364 If discussion results in a bright idea and you come up with a new
365 patch, normally you should post it to both mailing lists. The people
366 discussing on XEmacs Beta will want to know the outcome of the thread,
367 and you need to submit to XEmacs Patches as the "list of record."
369 If the old patch has been applied to CVS, then just submit the new one
370 as usual. If it has not been applied, then it is best to submit a new
371 patch against CVS. If possible do this as a reply to the original
372 patch post, or something following it in the thread. (The point is to
373 get the original patch post's Message-ID in your References header.)
374 In this case, also use the keyword SUPERCEDES in the Subject header to
375 indicate that the old patch is no longer valid, and that this one
378 These rules will result in a fair number of cross posts, but we don't
379 yet have a better way to handle that.
381 Note: Developers should never post to xemacs-patches unless there is a
382 patch in the post. We plan to enforce this with an automatic filter.
384 The exceptions are administrative. If you have commit authorization,
385 then post a short COMMIT notice to xemacs-patches when you commit to
386 CVS. Members of the Review Board will also post short notices of
387 administrative action (APPROVE, VETO, QUERY, etc) to xemacs-patches.
390 ====================================
392 [Note: these instructions have been partly updated, but not carefully
393 reviewed in some time. Caveat tester.]
395 Starting with XEmacs 21.1, much of the functionality of XEmacs has
396 been unbundled into "the packages." For more information about the
397 package system, see the Info nodes on Packages (in the XEmacs User
398 Manual) and on Packaging (in the Lisp Reference).
400 When bootstrapping XEmacs, you may need to manually install some
401 packages (at least xemacs-base and efs). These packages are available
402 by FTP at ftp://ftp.xemacs.org/pub/xemacs/packages/.
404 ** Binary package installation
405 ================================================
407 Prerequisite: XEmacs 21.0-b1.
409 Binary packages are complete entities that can be untarred at the top
410 level of an XEmacs package hierarchy and work at runtime. To install files
411 in this directory, run the command `M-x package-admin-add-binary-package'
412 and fill in appropriate values to the prompts.
414 ** Manual procedures for package management
415 ===========================================
417 Prerequisite: XEmacs 21.0
419 When adding and deleting files from a lisp directory the
420 auto-autoloads.el (global symbols) and custom-load.el (Customization
421 groups) must be kept in synch. Assuming one is manipulating a
422 directory called `lisp-utils', the command to rebuild the
423 auto-autoloads.el file is:
425 xemacs -vanilla -batch -l autoload -f batch-update-directory lisp-utils
427 The command to rebuild the custom-load.el file is:
429 xemacs -vanilla -batch -l cus-dep -f Custom-make-dependencies lisp-utils
431 To bytecompile both of these files the command is:
433 xemacs -vanilla -batch -f batch-byte-compile \
434 lisp-utils/auto-autoloads.el lisp-utils/custom-load.el
436 ** Building XEmacs and XEmacs packages from scratch
437 ===================================================
439 To build everything completely from scratch (not a high priority as a
440 design goal), the following procedure should work. (I don't recommend
443 *** Phase 1 -- Get a minimal XEmacs binary with mule to build the package
446 **** Grab a mule-base tarball and install it into a newly created package
449 **** Configure XEmacs with mule and a package-path including the
450 directory created above.
452 **** Do a `make dist' to build an XEmacs binary.
454 *** Phase 2 -- Build and install the package lisp.
456 **** Modify XEmacs.rules for local paths and the XEmacs binary created in
459 **** Do a make from the top level package lisp source directory.[1]
461 **** Do `make bindist's on all the packages you wish to install and
462 remove the byproduct .tar.gz's.
464 *** Phase 3 -- If necessary, redump XEmacs
465 with the packages that require dump-time support and install it.
467 **** Reconfigure without Mule if you don't wish a Mule-ish XEmacs, and
472 **** rm lib-src/DOC src/xemacs; make
474 **** Install or run in-place.
476 Note that this is in essence what `make all-elc' has always done.