OSX installer -- first draft
Gregory Collins
greg at gregorycollins.net
Tue Jun 2 09:47:57 EDT 2009
Duncan Coutts <duncan.coutts at worc.ox.ac.uk> writes:
>> Features/caveats:
>>
>> * it presupposes GHC-6.10.3 is installed from the binary distro. The
>> final release will bundle the two together in a .dmg file.
>
> So that's the weirdness wit the ghc .pkg being somehow incompatible
> with the tools right? Did we tell GHC HQ what versions of the tools
> you're using. Did you experiment with making a ghc .pkg yourself using
> your versions of the tools?
Honestly I think the GHC package is fine -- it was built by the OSX
tools and packages that I build have the same issues. I have to admit
that I don't understand the distribution package format the way that I
thought I did. When you unxar something like the GHC installer, you get
a directory structure that looks like this:
./Distribution
./ghc.pkg
./ghc.pkg/Bom
./ghc.pkg/PackageInfo
./ghc.pkg/Payload
./ghc.pkg/Scripts
./Resources
./Resources/en.lproj
./Resources/en.lproj/background
./Resources/en.lproj/License
"Distribution" and "PackageInfo" are XML files, "Payload" and "Scripts"
are gzipped cpio archives, and Bom is a "bill-of-materials file". If you
take a flat package and unxar it, you get:
./Bom
./PackageInfo
./Payload
./Scripts
Which made me think that the "ghc.pkg" directory inside the distribution
package is just an unxar'ed version of the flat package made by
packagemaker -- but it isn't. *Something* is subtly different, and I
haven't yet been able to unearth what it is (maybe I need to take my
crystal ball in for service?). If I try to extract the ghc.pkg directory
from the distro and xar it up into a flat package file, the Apple tools
choke on it with a "cpio error".
For flat .pkg files this isn't such an issue, because the command line
packagemaker tool will build those, but it won't build distributions so
for now I'm going to have to build them by hand.
> Perhaps later when you have a moment (which I appreciate may not be
> for some time) you could post about the details of what is supposed to
> work but doesn't. In particular if you have suggestions for how to
> change what ghc does for 6.12 that'd be useful. Eg, if combining .pkg
> files is totally broken, would it be preferable to build ghc and the
> platform packages together in one build tree rather than trying to
> merge/combine them later?
If you guys can get me a copy of the ghc.pkg flat file (i.e. the one
that gets bundled inside the final GHC-6.10.3-i386.pkg file), then I can
easily include it in the haskell platform distribution. Going the other
way is proving to be quite a challenge. I'm starting to wonder whether
"embarrassment" on the part of Apple engineers is the reason this stuff
is so under-documented.
G.
--
Gregory Collins <greg at gregorycollins.net>
More information about the Haskell-platform
mailing list