NAME:             emacs

VERSION:          23.1

DESCRIPTION:      GNU Emacs editor

LICENSE:          GPLv3

PACKAGE:          SUNWgnu-emacs SUNWgnu-emacs-el SUNWgnu-emacs-gtk SUNWgnu-emacs-nox SUNWgnu-emacs-x

PROJECT_URL:      http://www.gnu.org/software/emacs/

SOURCE_DOWNLOAD:  http://ftp.gnu.org/pub/gnu/emacs/emacs-23.1.tar.gz

SUPPORT:          C

BUGTRAQ:          solaris/utility/emacs

OSR:              13016

COMMENTS:         

	- This code is built with gcc. The primary reason for this

	  is that the configure script has problems using a non-GNU

	  cpp. I am not aware of any reason Sun Studio could not be

	  made to work, but simply made a cost/benefit decision not to

	  pursue it at this time.

	- I have made the following changes to the emacs sources:

	    buffer_menu.patch

		Fixes an issue with GTK and the Buffers menu where the

		menu contents is not updated to show the current buffers

		and instead shows a stale list. I based these patches

		on the official ones applied to the emacs development branch:

		http://lists.gnu.org/archive/html/emacs-diffs/2009-09/msg00039.html

	    src/s/sol2-5.h

		Use the system malloc instead of the built in one

	    src/s/sol2-6.h

		Use the native Solaris dldump() function (emacs/src/unexsol.c)

		to produce the dumped emacs, rather than the generic ELF

		code (emacs-22.1/src/unexelf.c).

	- Typically, emacs is built as either 32-bit or 64-bit,

	  depending on the target machine. The benefit of a 64-bit

	  emacs is that the size of the files it can handle is not

	  limited to 128MB, as it is with the 32-bit version.

	  For Solaris, we build both versions, using /usr/lib/isaexec

	  to run the 64-bit version if possible, and the 32-bit version

	  otherwise. Note that this is only done for the emacs binary

	  itself, as there is no technical need for 64-bit versions of

	  the ancillary programs that come with emacs (etags,

	  emacsclient, etc).

	  Fortunately, the vast majority of the files in an

	  emacs tree are identical, regardless of the platform

	  and/or word size, which makes this particularly easy to

	  do.

	  We create usr/lib/isaexec in our local proto, as well as the

	  files in usr/bin that link to it. This is done to allow testing

	  from the local proto. These files are not delivered to the real

	  proto. They are created on the users machine by the packaging system.

	- There are three different toolkit options: None, Athena widgets

	  (aka Xaw, or lucid), and gtk.

	- We deliver the following packages, in package cluster SUNWCgnu-emacs:

		SUNWgnu-emacs - This contains the core emacs distribution,

			minus the emacs binaries.

		SUNWgnu-emacs-gtk - Binaries for the X11 version using the

			GTK widget toolkit.

		SUNWgnu-emacs-nox - Pure tty emacs binaries, built without

			any X11 linkage.

		SUNWgnu-emacs-x - Binaries for the X11 version using the

			Athena widget (Xaw) toolkit.

		SUNWgnu-emacs-el - The compressed LISP files for which compiled

			versions are delivered by SUNWgnu-emacs.

	  SUNWgnu-emacs is required by the other packages.

	  Note that earlier versions (22.1) of SUNWgnu-emacs-gtk did not

	  deliver sparcv9 binaries, as there were unresolved GTK issues.

	  This appears to be solved in emacs 23, and we now deliver the

	  sparcv9 binaries.

	- The emacs Makefile install rule does more than copy files around.

	  It runs emacs in batch mode to generate compiled lisp files,

	  compresses uncompiled lisp files, and performs other arbitrary

	  actions we'd rather not have to duplicate.

	  The problem is that the install rule is intended to install the files

	  in their final location, whereas we want to deliver them into the proto

	  area, package them, and then have the packages eventually install them.

	  If we configure the makefile to point at the proto, the results will

	  be wrong at runtime (emacs is aware of its installation location).

	  My solution to this is as follows:

		- Makefile.sfw configures emacs for its final installation

		  location, causing the binaries and lisp code to contain

		  the proper final paths.

		- Makefile.sfw runs the emacs makefile install rule to populate

		  a local proto directory by overriding the Make variables

		  used to place the files.

		- install-sfw copies the files from the local proto directory

		  into the workspace proto.

		- Packing then proceeds as usual

	  When upgrading the version of emacs, you should be careful to test

	  and ensure that this trick still works. Also, different versions of

	  emacs are likely to have a slightly different list of files that are

	  delivered and packaged. The best way to determine this is to change

	  PREFIX in install-sfw to an empty scratch directory, run it, and then

	  examine the files that are installed there.

	- To produce the Solaris emacs packages, we need to build the

	  emacs tree multiple times, using slightly different options

	  each time. The build_emacs script is used to encapsulate this

	  process.

	- We do not install the files under /var/games/emacs. The reason for

	  this is that we do not install update-game-score as setuid, and

	  therefore the game files are not usable. This the same decision made

	  by Debian, among others.