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.