OSX installer -- another status update

[Manuel M T Chakravarty]

Ian Lynagh:
> On Sun, May 24, 2009 at 11:51:53PM +0000, Duncan Coutts wrote:
>> On Thu, 2009-05-21 at 10:02 -0400, Gregory Collins wrote:
>>> Hi all,
>>>
>>> I'm making progress on the OSX installer front, torturously slow  
>>> though
>>> it may be. I wasted most of Tuesday trying to bundle GHC's OSX  
>>> installer
>>> inside the Haskell platform distribution -- it looks like GHC's
>>> installer is broken somehow as the GUI tools choke on it, saying  
>>> "Could
>>> not unarchive package payload". This, despite cpio handling it just
>>> fine?
>>
>> We can check with Ian how the OSX pkg is built, what versions of  
>> tools
>> he is using. Now is a good time to work this out since there will  
>> be a
>> new one for the ghc-6.10.4 release, so there's the opportunity to  
>> make
>> changes to details of how the pkg is built, or versions of tools  
>> used.
>
> In a GHC source tree, see the framework-pkg target in
> distrib/MacOS/Makefile for how the packages are made (if you want to
> run it yourself then note that you need to ./configure first. Also,  
> I'm
> not sure if it works properly in the HEAD at the moment, so it's  
> best to
> use the 6.10.3 release).
>
> If you want to know what tool versions I use, just let me know what  
> info
> you need.
>
> I'm not familiar with the details of how the package creation works,  
> but
> Manuel wrote it so if you have any questions then perhaps he will be
> able to answer them.

The basic idea is simple.  I use Xcode (version 3.0) to create the  
layout of a framework (called GHC.framework).  Then, Xcode invokes the  
standard GHC build process and gets it to install the build products  
into the GHC.framework (using the usual file system layout, but within  
the framework).  Afterwards, I invoke PackageMaker to build the .pkg  
from the framework.

I think this is the Right Way to handle GHC's installation on Mac OS  
X, considering the platform guidelines in Apple's bundle programming  
and distribution guidelines.  Nevertheless, there are a few variants  
to consider:

* One could write a shell script to create the GHC.framework layout  
instead of using Xcode for it.  This would have the advantage to take  
Xcode out of the loop.  However, it also has the disadvantage that the  
generation of the framework meta data and filesystem structure needs  
to be accurately replicated and kept up-to-date as new versions of  
Xcode are released.  Given that the use of GHC on Macs requires Xcode  
anyway (as it includes the developer tools, such as gcc), using Xcode  
seems overall simpler.

* I used the PackageMaker GUI to create the package layout and store  
it in a pmdoc file.  I think, it would be possible to not have a pmdoc  
file, but to instead invoke the command line version of packagemaker  
with all the right options right from within the Makefile.  I didn't  
realise that when I started adding support for .pkg generation, but I  
now think a pure command-line-based setup would be preferable (after  
all, we need to use some command line options anyway and then  
everything would be in one place).

* It would be desirable to generate relocatable .pkgs, but that is  
currently impossible (at least in a clean manner).  Relocatable GHC  
distributions (ie, bindists) work by installing and hence actually  
moving all files around in the file system.  However, Mac OS X pkgs  
are not supposed to move files around.  Instead, the Mac package  
installer puts everything at the right place and the package scripts  
should adjust everything to that location *inplace*.  (Otherwise that  
whole package receipt stuff -including "Repair Permissions" in  
DiskUtility- doesn't work.)

IMO the right way to go for the Haskell Platform is to generate a  
*meta* package (.mpkg) with the GHC.framework in one subpackage and  
the various other components of the HP in further subpackages.  These  
additional subpackages should probably all install into /Library/ 
Frameworks/Haskell.framework.  If cabal-install is used to download  
and install further packages, they need to go into either /Library/ 
Frameworks/Haskell.framework for systemwide installations or into  
$HOME/Library/Frameworks/Haskell.framework for user-specific  
installations.

Manuel