Mac OS X GNU Emacs Installer (make-package)

Mac OS X GNU Emacs Installer (make-package)

[Steven Tamm]

I just checked in a bunch of changes to the make-package installer.  
They are reduce the size of the installer and the amount of disk space 
required.  Before the changes the disk image for the installer was 25.6 
MB after compression, now it is 16.4MB with no compression.  In fact, 
compression doesn't really reduce the size that much so the script 
doesn't bother.

By default, it no longer installs the .el files that are precompiled 
(use --full-dist to bring them back).  If you specify the --symlink 
flag, the Emacs binary inside the Carbon Emacs.app will be a symlink to 
$prefix/bin/emacs.   This makes the Emacs app very small (60K), which 
is probably a good thing.  I also added a flag to create self-contained 
binaries (where the binary is placed in 
Emacs.app/Contents/Resources/bin).  There were some other changes too, 
but not really that important.  I'd suggest rerunning make-package if 
you are running out of bandwidth on your site.

For the list: Why does "make install" install two identical copies of 
the executable; emacs & emacs-21.3.50?  Why is emacs not a symbolic 
link?

-Steven

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

[Kai Großjohann]

Steven Tamm <steventamm@mac.com> writes:

> For the list: Why does "make install" install two identical copies of
> the executable; emacs & emacs-21.3.50?  Why is emacs not a symbolic
> link?

The two files are supposed to be hard links.  Maybe something is
going wrong to prevent this.
-- 
~/.signature is: umop ap!sdn    (Frank Nobis)

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

[David Caldwell]

On 11/30/02 2:23 PM -0800 Steven Tamm wrote:

> For the list: Why does "make install" install two identical copies of the
> executable; emacs & emacs-21.3.50?  Why is emacs not a symbolic link?

It's a hard link... ls -i and check that the inodes are the same number.

I have some patches for make-package as well. Should I send them to the 
list?

One of them adds some code to copy some files out of a staging directory 
into the root directory of the disk image. IE. readme, COPYING, etc. The 
staging directory is empty by default, so it's up to the packager to put 
what they want in there...

The second one is more controversial, I think. I made a little shell 
wrapper that launches the Emacs.app so that typing plain "emacs" in the 
shell doesn't segfault. Since the user should be free to move his 
/Applications/Emacs.app around as he sees fit, I can't call that wrapper. 
So I made a duplicate app wrapper in libexec. I hard linked it to the emacs 
exe in /Applications/Emacs.app so it doesn't take up any more room in the 
disk image, nor on the system. It has complete transparency to the user, I 
think.

Are you interested in either patch?

-David

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

[Steven Tamm]

On Saturday, November 30, 2002, at 02:48  PM, David Caldwell wrote:

> On 11/30/02 2:23 PM -0800 Steven Tamm wrote:
>
>> For the list: Why does "make install" install two identical copies of 
>> the
>> executable; emacs & emacs-21.3.50?  Why is emacs not a symbolic link?
>
> It's a hard link... ls -i and check that the inodes are the same 
> number.

Now I feel like an idiot.  I even checked for that, but in the wrong 
directory.  I'll revert it, test it, and check it in.

>
> I have some patches for make-package as well. Should I send them to 
> the list?

Yes, please.

>
> The second one is more controversial, I think. I made a little shell 
> wrapper that launches the Emacs.app so that typing plain "emacs" in 
> the shell doesn't segfault. Since the user should be free to move his 
> /Applications/Emacs.app around as he sees fit, I can't call that 
> wrapper. So I made a duplicate app wrapper in libexec. I hard linked 
> it to the emacs exe in /Applications/Emacs.app so it doesn't take up 
> any more room in the disk image, nor on the system. It has complete 
> transparency to the user, I think.

This is the solution that Andrew proposes.  /usr/local/bin/emacs would 
be a shell script that calls /usr/local/bin/emacs-21.3.50 -nw $*.  I 
don't like that solution very much.  This is a patch I placed on the 
list earlier; it causes the executable to determine if it is inside an 
application bundle.  If it is not, it will cause it to 
inhibit_windowing_system.  I placed the call to this right after the 
call to init_mac_osx_environment inside emacs.c:main

/* Determine if the executable is not in a bundle, and if so, do not 
attempt
    to start up the window system */
void
mac_determine_bundle_status()
{
#if MAC_OSX
   extern int inhibit_window_system;
   extern int noninteractive;
   CFBundleRef appsBundle;

   /* No need to test if already -nw*/
   if (inhibit_window_system || noninteractive)
     return;


   appsBundle = CFBundleGetMainBundle();
   if (appsBundle != NULL)
     {
       CFStringRef cfBI = CFSTR("CFBundleIdentifier");
       CFTypeRef res = CFBundleGetValueForInfoDictionaryKey(appsBundle, 
cfBI);
       /* We found the bundle identifier, now we know we are valid. */
       if (res != NULL)
	{
	  CFRelease(res);
	  return;
	}
     }

   /* Unless we actually find the resource, set -nw */
   inhibit_window_system = 1;
#endif
}

BTW, I think making  Contents/MacOS/Emacs be a hard link to 
emacs-21.3.50 is a bad idea.  The Application may (and in my case 
usually will) live on a different volume than the /usr/local tree.  
I'll keep the symlink option there for the Application, but remove the 
bad behavior.

-Steven

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

[David Caldwell]

On 11/30/02 3:19 PM -0800 Steven Tamm wrote:

> On Saturday, November 30, 2002, at 02:48  PM, David Caldwell wrote:
>
>> On 11/30/02 2:23 PM -0800 Steven Tamm wrote:
>>
>> I have some patches for make-package as well. Should I send them to
>> the list?
>
> Yes, please.

Ok. I'll do so shortly.

>> The second one is more controversial, I think. I made a little shell
>> wrapper that launches the Emacs.app so that typing plain "emacs" in
>> the shell doesn't segfault. Since the user should be free to move his
>> /Applications/Emacs.app around as he sees fit, I can't call that
>> wrapper. So I made a duplicate app wrapper in libexec. I hard linked
>> it to the emacs exe in /Applications/Emacs.app so it doesn't take up
>> any more room in the disk image, nor on the system. It has complete
>> transparency to the user, I think.
>
> This is the solution that Andrew proposes.  /usr/local/bin/emacs would be
> a shell script that calls /usr/local/bin/emacs-21.3.50 -nw $*.  I don't
> like that solution very much.  This is a patch I placed on the list
> earlier; it causes the executable to determine if it is inside an
> application bundle.  If it is not, it will cause it to
> inhibit_windowing_system.  I placed the call to this right after the call
> to init_mac_osx_environment inside emacs.c:main
[..]

That was my initial idea. But in the end I like the way the shell script 
works better. Typing plain "emacs" gives you a new window, while "emacs 
-nw" gives you the console. It works just like under X Windows. Otherwise 
there is no way to get a nice window from the command line, except by 
writing your own shell wrapper. To me that is the only reason to choose the 
shell script road over the patch you propose (Although I think patch should 
be there as well, since emacs should never segfault).

> BTW, I think making  Contents/MacOS/Emacs be a hard link to emacs-21.3.50
> is a bad idea.  The Application may (and in my case usually will) live on
> a different volume than the /usr/local tree.  I'll keep the symlink
> option there for the Application, but remove the bad behavior.

The question is, does the installer (or pax) automatically copy the file if 
it's getting unloaded accross filesystems? If so then there's no problem 
with a hard link.

-David

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

[Steven Tamm]

>> This is the solution that Andrew proposes.  /usr/local/bin/emacs 
>> would be
>> a shell script that calls /usr/local/bin/emacs-21.3.50 -nw $*.  I 
>> don't
>> like that solution very much.  This is a patch I placed on the list
>> earlier; it causes the executable to determine if it is inside an
>> application bundle.  If it is not, it will cause it to
>> inhibit_windowing_system.  I placed the call to this right after the 
>> call
>> to init_mac_osx_environment inside emacs.c:main
> [..]
>
> That was my initial idea. But in the end I like the way the shell 
> script works better. Typing plain "emacs" gives you a new window, 
> while "emacs -nw" gives you the console. It works just like under X 
> Windows. Otherwise there is no way to get a nice window from the 
> command line, except by writing your own shell wrapper. To me that is 
> the only reason to choose the shell script road over the patch you 
> propose (Although I think patch should be there as well, since emacs 
> should never segfault).

Yeah, I think you are right.  The one concern that I had was what would 
happen if the location of the Emacs.app was moved.  Your solution fixes 
that by creating a "shadow" application.  Why not make the whole 
Emacs.app directory be a link to the lib-exec one?  That way you 
wouldn't have the problem of dealing with two sets of files depending 
on whether you did it from the command line or from the finder.  The 
downside is that the icon in the Applications menu would be a little 
screwed up.

As another aside, I think the make-package script should eventually be 
rewritten in perl because of the guarantee that it exists on Mac OS X.  
Any objections.

>> BTW, I think making  Contents/MacOS/Emacs be a hard link to 
>> emacs-21.3.50
>> is a bad idea.  The Application may (and in my case usually will) 
>> live on
>> a different volume than the /usr/local tree.  I'll keep the symlink
>> option there for the Application, but remove the bad behavior.
>
> The question is, does the installer (or pax) automatically copy the 
> file if it's getting unloaded accross filesystems? If so then there's 
> no problem with a hard link.

If Emacs.app is a symlink then it's a non-issue (obviously).  pax at 
that point is just a wrapper around tar (see the man page), so I would 
assume it would do the right thing in any case.

-Steven

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

[Miles Bader]

On Sat, Nov 30, 2002 at 05:53:05PM -0800, Steven Tamm wrote:
> As another aside, I think the make-package script should eventually be 
> rewritten in perl because of the guarantee that it exists on Mac OS X.  
> Any objections.

You mean script that currently uses /bin/sh?

I really don't think /bin/sh is going to go away...

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

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

[Steven Tamm]

>
>> As another aside, I think the make-package script should eventually be
>> rewritten in perl because of the guarantee that it exists on Mac OS X.
>> Any objections.
>
> You mean script that currently uses /bin/sh?
>
> I really don't think /bin/sh is going to go away...

Oh that's not what I meant at all, but it is what I wrote.

I think the script would be easier to maintain in perl than in /bin/sh. 
  This is only interesting because Perl is guaranteed to be on the 
system (unlike most *nix flavours).

-Steven 

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

[Richard Stallman]

    > As another aside, I think the make-package script should eventually be 
    > rewritten in perl because of the guarantee that it exists on Mac OS X.  
    > Any objections.

    You mean script that currently uses /bin/sh?

I don't know Perl, so please avoid Perl code in Emacs.

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

[David Caldwell]

On 11/30/02 5:53 PM -0800 Steven Tamm wrote:

> Yeah, I think you are right.  The one concern that I had was what would
> happen if the location of the Emacs.app was moved.  Your solution fixes
> that by creating a "shadow" application.  Why not make the whole
> Emacs.app directory be a link to the lib-exec one?  That way you wouldn't
> have the problem of dealing with two sets of files depending on whether
> you did it from the command line or from the finder.  The downside is
> that the icon in the Applications menu would be a little screwed up.

I really wanted to do cp -lr but OS X cp doesn't support -l. In the end I 
did this:

[david@Bluey ~/src/emacs-dev/emacs-cvs/mac]$ find /Applications/Emacs.app 
-type f | xargs du -s
8       /Applications/Emacs.app/Contents/.cvsignore
8       /Applications/Emacs.app/Contents/Info.plist
14168   /Applications/Emacs.app/Contents/MacOS/Emacs
8       /Applications/Emacs.app/Contents/PkgInfo
104     /Applications/Emacs.app/Contents/Resources/Emacs.icns
16      /Applications/Emacs.app/Contents/Resources/Emacs.rsrc
8 
/Applications/Emacs.app/Contents/Resources/English.lproj/InfoPlist.strings

And decided that it was negligible to have a complete copy in libexec (as 
long as Contents/MacOS/Emacs was a link...).

> As another aside, I think the make-package script should eventually be
> rewritten in perl because of the guarantee that it exists on Mac OS X.
> Any objections.

I'm a big perl fan so you won't hear objections from me :).

> If Emacs.app is a symlink then it's a non-issue (obviously).  pax at that
> point is just a wrapper around tar (see the man page), so I would assume
> it would do the right thing in any case.

Symlinking the whole app works just as well. The only "downside" is that 
you get the little alias stamp on the icon. It doesn't really matter to me 
if it's a symlink or a hard link. I can't see what either one offers over 
the other one (in this case).

-David

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

[Andrew Choi]

Steven Tamm <steventamm@mac.com> writes:

> [...]  This is the solution that Andrew proposes.
> /usr/local/bin/emacs would be a shell script that calls
> /usr/local/bin/emacs-21.3.50 -nw $*.  I don't like that solution very
> much.  This is a patch I placed on the list earlier; it causes the
> executable to determine if it is inside an application bundle.  If it
> is not, it will cause it to inhibit_windowing_system.  I placed the
> call to this right after the call to init_mac_osx_environment inside
> emacs.c:main

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 "$@"

(or whatever path leading to it).  This way you get the application in
the Finder, and you can start it from the command line, in either GUI or
terminal mode.  And since the executable is always placed in the
application bundle, there's no danger of it not finding its resources.
I'm not against simply printing an error message and exiting or adding
your patch, which starts Emacs in terminal mode (possibly after printing
out a warning message) if someone has unknowingly moved it outside the
application bundle.

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've also remove mac/make-bin-dist and mac/osx-install, which are
obsolete now.  Perhaps we should mention make-package in mac/INSTALL.

Andrew.

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

[Richard Stallman]

    Are you interested in either patch?

I will leave it to the people who work on Emacs for MacOS to decide
whether these are good changes.  However, I'd like to ask how big the
patches are.  I want to see whether we need legal papers before we can
use them, to make the necessary arrangements.

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

[Richard Stallman]

    By default, it no longer installs the .el files that are precompiled 
    (use --full-dist to bring them back).

Please change this so it installs the .el files by default.
We should encourage people to install the source.

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

[Stefan Monnier]

> By default, it no longer installs the .el files that are precompiled 
> (use --full-dist to bring them back).  If you specify the --symlink 

Please leave all the .el files in.  They're useful documentation
and we want to encourage people delving into that code.


	Stefan

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

[Steven Tamm]

>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

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

[Andrew Choi]

Steven Tamm <steventamm@mac.com> writes:

> >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.

This is also fine with me.

IIRC, having Emacs (in the application bundle) as a symlink didn't work
in an earlier version of OS X (10.0 I think).  Strangely it worked in
Public Beta.  In any case I don't think there are users of either
version of OS X any more.