Mac HP directory naming

[George Colpitts]

I vote for tie to GHC release


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

> Other compilers/programs generally tie the "platfrom" release into the
> language and compiler/interpreter release.
>
> Python is a good example: 2.7.2 is the version number of both a release of
> the language, the standard interpreter, and the 100s of libraries that come
> with it. The librarys are not individually versioned: That is, once
> something is accepted into the base set, it submits itself to be managed
> and release by the core Python team. Similarly, the core Python team
> includes all the libs in the release process.
>
> The normal packaging allows multiple x.y Python releases, but only one
> x.y.z for a given x.y. So my system has on it 2.5.6, 2.6.7, and 2.7.2 on it
> right now. If I load 2.7.7, it would (normally) replace 2.7.2.
>
> Ruby and Perl follow pretty much the same model. Of course, architecture
> doesn't really come into play for these. Erlang, Ocaml, and Go don't
> support (by default) versioned installs. Scala pretty much punts to the
> user, letting them unpack the tarfile whereever they want... and then hand
> configure environment variables!
>
> Most of the above languages come bundled with what we'd call the
> "platform" libraries. Though how extensive those packages are varies a bit.
>
> Notably none of the compiler systems attempt to let the user install
> multiple architectures (32bit and 64bit) at the same time.
>
> ====
>
> So, I guess we could take on of these paths:
>
> *Punt:* Allow one GHC and one Haskell Platform to be installed at a time.
> While we've had the directory structure to (almost) support multiple
> installs, we've never really supported it.
>
> *Tie to GHC release: *This is easiest, because one can add, remove, and
> switch between releases easily: It is just switching directories and
> symlinks. Realistically, we've only ever once released two HPs for the same
> GHC, and it was a point release. It is probably safe to say that two major
> release of HP will never use the same compiler.
>
> If we go this route, the logical thing is to keep the sub directory under
> /Library/Haskell named for the ghc release, but include the architecture:
> That is, go from ghc-x.y.z to x.y.z-arch (which would be the same as the
> compiler) - it makes the link clear. BUT, this removes the version name of
> the HP: Nowhere does the tree contain 2014.2! Perhaps we should rename
> Haskell Platform release to simply follow GHC:  HP 7.8.3  and 7.8.3.x for
> point releases?
>
> *Keep the independence:* As usual, Haskell is forging new ground here...
> hence why we're a bit a drift. The uninstaller might just be flaky for now
> if we go this route, as I'm not sure I want to spend the next two weeks
> recoding that... holding up an alpha HP.
>
> - Mark
>
>
>
>
>
> _______________________________________________
> Haskell-platform mailing list
> Haskell-platform at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20140702/af91a5f9/attachment.htm>