> * We now use a single root directory for both GHC and
> extralibs
> ($PROGRAMFILES\Haskell Platform\$HP_VERSION).
Is this location configurable? Is it baked into any code?
What is the directory structure below the root?
> * Installed files are tracked precisely (no unsafe `rm -rf`
> business).
Thanks!
> * A new installation mode which doesn't touch the system
> settings or registry was introduced.
Thanks, that is good to know. Combined with uninstall and better
compression, that means I'll actually want to use this for a GHC 6.10.3
installation (when things are stable;-), to replace my ageing GHC 6.8.3
(which I mostly use to build GHC head, and to check what non-head
users can see on their systems). Will all files be extracted under the root?
Could you please provide some details about what the default
installation mode will do to the system settings or registry, so that
people can make an informed choice about which installation mode
to use? File types used, associated actions, default actions, PATH
settings, other settings (?), what happens to existing settings, how
does the installer integrate with existing installations of GHC, Cabal,
WinHugs, ...?
In terms of integrating with existing Cabal, I assume the installer
does not actually include a pre-populated Cabal, but only a pre-
populated GHC package database and the Cabal install tool, and
will not overwrite existing '<path>/Application Data/cabal' or
'<path>/Application Data/ghc/ghci.conf'. Is that correct?
Btw, is GHC the only implementation currently included in the HP?
> * Installer size was cut down by 50% by turning on 7z
> compression (thanks to Bulat Ziganshin for the heads-up).
Great!
> * glut32.dll is not included, though it probably should be.
While this is consistent with the last GHC installers that did provide
GLUT at all, those had seen a steady increase in we-want-to-get-rid-of-this
by GHC HQ even before the Haskell Platform initiative was announced,
and when the HP appeared on the horizon, the idea became that "the HP
will address this properly, so we don't have to". So it isn't a good idea
to take a lead from recent GHC installers, as far as GLUT is concerned.
The earlier installers (provided by Sigbjorn via unknown means;) were
more complete, but the later installers (using automated installer generation)
often suffered from missing packages or missing package components
(when the installer builder's machine didn't have glut installed, GLUT
wouldn't be built, so not included at all, and even if glut was installed,
glut32.dll would usually be in a place from which the installer builder
wouldn't copy it until told to do so explicitly).
I've always had difficulties understanding the advantage of providing
GLUT in an incomplete and unusable form (glut32.dll is some 200K
uncompressed, GLUT can't be used without it, and the dll is from the
same non-Haskell package that provides glut.h as well, so why include
one but not the other?). Finding and adding a dll is easier than building
the package, but for a Haskell Platform release this is bordering on the
ridiculous, isn't it?-)
"Batteries included, but you'll have to buy the lightbulbs separately,
sorry"
If it is a question of location, put it in a non-active directory, to be
moved (as I've been doing on my system) where Cabal installs its
executables. That would avoid installing any files outside the HP
root directory while still providing a complete package.
Of course, it is up to the person doing the work to decide, but I
thought I'd make a last attempt to persuade you!-) Either way, thanks
for your efforts!
A general comment (not windows specific): since OpenGL/GLUT
were dropped -in premature anticipation of HP's arrival- from the
GHC installers long ago, it would have been good to communicate
with the hopengl mailing list on the OpenGL/GLUT-specific aspects
of the Haskell Platform.
There had been quite a few patches piling up there, of which the HP
organizers haven't been aware, and I doubt that many of that list's
readers are aware of how the details of the HP process will affect
them. They have been waiting under the assumption that the HP
will fix their packages so that things will "just work" again, for them
and their clients.
Claus
_______________________________________________
Haskell-platform mailing list
Haskell-platform@projects.haskell.org
http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
