emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mac OS X GNU Emacs Installer (make-package)


From: Steven Tamm
Subject: Re: Mac OS X GNU Emacs Installer (make-package)
Date: Mon, 2 Dec 2002 11:22:03 -0800 (PST)

>Hi Steven,
>
>Actually the idea (which hasn't been implemented) was to have `make
>install' install only one executable on the entire system: the one in
>the Emacs.app application bundle.  Then /usr/local/bin/emacs would be
>the shell script:
>
>#!/bin/sh
>/Applications/Emacs.app/Contents/MacOS/Emacs "$@"
>

Actually, I think this is a good idea, but in the reverse.  I would have the 
single copy of the executable in /usr/local/bin/emacs and have the Emacs 
executable be a link (either sym or hard).  The main reason is that it is 
likely to have the application move, but extremely unlikely that 
/usr/local/bin/emacs would move.

I have a patch that tests if -nw is not specified and we are not in an 
application bundle (i.e. in /usr/local/bin/emacs), then fork and execute 
/Applications/Emacs.app/...   This makes the behavior from the command line 
more desirable.  The downside (as David) is that it will be confusing for most 
Mac users.  Two or more emacs executables will be running at the same time with 
each appearing in the dock as a separate icon.  This behavior is better than 
the current one, and using Launch Services, we can find the location of the 
Emacs application without resorting to hard coding or using libexec.

The behavior I would like to have the command line appear to act more like 
emacsclient (or more appropriately the gnuclient from the NT port).  The 
gnuclient port will, by default, instantiate emacs if one does not exist, 
something you need to do set by hand with emacsclient.  It would also require 
that the server is started, which is questionable.

>I don't have a strong preference to implement package distribution one
>way or another.  But I was considering the different options one can
>specify for make-package, which will result in the quite a few
>differently-configured packages people can distribute.  I also think
>some of the options are not achievable by people building from source
>using `make', which is a little strange.  Imagine the amount of
>questions we'll be getting :-).

I think I'll add in some documentation detailing about what to do.  After all 
the discussions on version tracker, I think a "strong" admonition about not 
using --prefix=/usr should be included (since, at least on my system, 
/usr/bin/emacs has been destroyed by system updates twice).

>I've also remove mac/make-bin-dist and mac/osx-install, which are
>obsolete now.  Perhaps we should mention make-package in mac/INSTALL.

I'll add in an explanation of make-package today.

On another note, I'm probably going to put in an #ifdef in terminfo.c to remove 
the redefinition of UP, BC, & PC on darwin 6.2.  This will fix some linking 
warnings.  This test should probably should be placed in configure.in.  
Something like this:

AC_MSG_CHECKING(whether termcap global variables are defined externally)
AC_TRY_LINK([extern char 
*UP;],[*UP=0],[termcap_global_vars_extern=yes],[termcap_global_vars_extern=no])


-Steven




reply via email to

[Prev in Thread] Current Thread [Next in Thread]