Mac HP directory naming

[Bob Ippolito]

On Wed, Jul 2, 2014 at 7:50 AM, Mark Lentczner <mark.lentczner at gmail.com>
wrote:

> Ah, it is a historical artifact, now enshirned in the build tools. GHC
> central produced an installer package that put the compiler in
> /Library/Frameworks/GHC.framework (which is sort of the "correct" place on
> Mac OS X). HP then added an installer package that put stuf in
> /Library/Haskell (also "correct" by Mac OS X standards - see
> /Library/Python etc...) The HP then included a meta-package that installed
> both of those.
>
> Now that the HP build builds the GHC portion from the bindist, I suppose I
> could configure it all to be under /Library/Haskell - though that would now
> deviate from how Python and Ruby were set up by Apple (they have dual
> prefexes one for libs one for interpreter).
>

The way they were set up by Apple only works well for them, you shouldn't
strive to do what they do. Here are the installation locations for Python
3.4 from python.org, for example:

$ find Python.mpkg -name Info.plist -exec grep -A1 IFPkgFlagDefaultLocation
{} \;|awk '/<string>/ { gsub("[ \t]*</?string>", ""); print }'
/Applications/Python 3.4
/Library/Frameworks/Python.framework/Versions/3.4/Resources/English.lproj/Documentation
/Library/Frameworks/Python.framework
/Library/Frameworks/Python.framework
/Library/Frameworks/Python.framework
/usr/local/bin

Ruby doesn't have a first party installer for Mac. The closest things to HP
would be RailsInstaller or the Bitnami Ruby Stack I suppose. These both
appear to use a commercial install tool (bitrock installbuilder) that
doesn't have metadata that I can easily inspect without running the
installer or digging into how they build them and how that tool works.

The only benefit to having untied releases is that in theory, if, say, HP
> 2014.2.0.0 and HP 2014.4.0.0 both used the same compiler (7.8.3), then one
> could have them both installed at the same time - which would benefit
> perhaps a few developers who want to back test against three or more HPs.
> The downside of tying to the HP release in such a case, is that the
> duplicate GHC portion is another ~750MB.
>

Doesn't sound like a worthwhile benefit to me and I assume it's rather rare
that HP releases share the same compiler version. It's just so much less
complex and much less likely for anything to go wrong if the packages
aren't designed to overwrite and/or share files in any way.

There's additional downside to having two HPs installed with the same
compiler version: ~/.ghc will be shared. That sounds like a special circle
of cabal hell.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20140702/adfd13f9/attachment.htm>