Mac HP directory naming

[Bob Ippolito]

I would tie it to the platform release. What's the benefit of having two
installs share the same compiler files? Why not just have completely
separate prefixes for each platform release?

On Wednesday, July 2, 2014, George Colpitts <george.colpitts at gmail.com>
wrote:

> I vote for tie to GHC release
>
>
> On Wed, Jul 2, 2014 at 10:13 AM, Mark Lentczner <mark.lentczner at gmail.com
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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/b042d116/attachment.htm>