Mac OS installer for Haskell platform

[Gregory Collins]

Duncan Coutts <duncan at haskell.org> writes:

> Sorry, I've been terrible at keeping up with this.
>
> The good news is we now have a project mailing list:
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
>
> I very much encourage you to register.

Will do, very shortly.

Also I have a git repository containing my work-in-progress up at:

  http://github.com/gregorycollins/cabal2macpkg/tree/master

I haven't gotten too far yet, I was hoping to get a little more done on
this over the holidays than I managed.


> Does that mean we're installing the platform packages inside the GHC
> framework? Is that a good idea?

Probably I'll add a "--prefix" argument to the program so that we can
defer the decision until later.


>>    $ cabal build
>>    $ cabal haddock
>>    $ cabal copy --inplace
>
> It might be easier or cleaner to copy --destdir= to some image
> directory.

That's what I ended up doing, because "--inplace" didn't work for me.


>>    $ cabal register --global --gen-script
>
> Similarly you can specify an actual file --gen-pkg-config=
> ...
> You can use the gen script if you like, but honestly I'm rather
> suspicious of it. I would do it with --gen-pkg-config= which outputs
> the file you pass to ghc-pkg register/update. Just a suggestion, it's
> up to you of course.
>

As far as I can tell, --gen-script makes a shell script that pipes the
output of "--gen-pkg-config" through "ghc-pkg update -". (Which is
exactly what I wanted, I think)


>>   * download each of the source packages (I wish "cabal fetch" took an
>>     "-o" argument)
>
> Hmm. File a ticket if you like.

Done, as #453.


>> One issue on MacOS is that OSX installer packages don't allow for an
>> "uninstall" option, so if we want to be good citizens we'll have to
>> bundle an uninstall program along with the distribution --- although
>> from what I can tell, if we're careful to leave everything inside
>> /Library/Frameworks/GHC.framework, we can piggyback on the existing GHC
>> uninstaller.
>
> Ah, so perhaps that's one reason to do it. If it is separate then we
> need to ghc-pkg unregister each package that we register and remove
> any symlinks we made.
>
> You could ask on the libraries list whether people think it's better
> to put things in the GHC framework or not.

That's where GHC currently plops all of the base libraries,
anyways. Which list do you mean, by the way?

G.
-- 
Gregory Collins <greg at gregorycollins.net>