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 _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
