Windows Installer RC

[Claus Reinke]

>> >      ($PROGRAMFILES\Haskell Platform\$HP_VERSION).
>> Is this location configurable?
>
> Of course you can change the install location. You'll have to
> edit packages.conf manually, though, if you'll later decide to
> move the Haskell Platform directory somewhere else.

? .. checking .. argh!*&  - thanks for pointing out that misfeature:

Pre Cabal, ghc installations were *relocatable* (no hardcoded absolute
paths, everything relative to where ghc is). Some of us have occasionally
used that to run ghc from a usb drive or a network-mounted directory
when giving presentations with demos on someone else's machine (eg,
the one installed in a lecture theatre).

Now, ghc's package.conf is full of absolute path references for cabal-installed
packages. I consider this regression a serious bug in cabal install (following
existing convention, it could have created a $cabaltopdir indirection, similar
to $topdir and $httptopdir). Though it isn't always clear where to get those
values from - in this case, cabal would have to register a value for $cabaltopdir
with ghc-pkg, and ghc-pkg would have to have an interface for such things
as querying and setting database variables.. (so I guess that means tickets
in both ghc and cabal are called for?).

>> What is the directory structure below the root?
>
> GHC installation is under $INSTDIR/ghc-$GHC_VERSION, and
> extralibs are under $INSTDIR/extralibs. Uninstaller is under
> $INSTDIR/Uninstaller.exe.

"extralibs"? I thought those were gone, eg., the platform would just be
a pre-populated ghc installation, with nothing to distinguish former extralibs
from packages installed later (actually, given that structure, all packages,
including those added later, will be installed under "extralibs", right?).

>> 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?
>
> By default, the installer:
>
>   1. Unpacks all files to the specified location (mandatory)
>
>   2. Updates packages.conf (mandatory)

That is the packages.conf that comes with the ghc being installed by
the same installer, right? So it doesn't change any existing databases, just
makes sure that the newly installed ghc knows about its initial population
of packages.

>   3. Associates .hs/.lhs files with GHCi (optional)

How, exactly? I've seen different Haskell implementations use different
filetypes for the same ending (so the old actions were bypassed completely
because the .hs ending got associated with a different file type), on occasion
even different association methods (using a low-level interface, one can
apparently create a filetype association that is not easily visible/editable
via the standard user interface, which meant that the folder options dialogue
would show me one thing for haskell files, while clicking on haskell files
did something completely different).

This should be specified in reliable form, preferably compatible with
the earlier agreements mentioned in the installer ticket comments (so that
when Neil follows those, his WinHugs installer won't have to fight with
the HP installer over who gets a say in working with haskell files; similarly
for the bare-bones GHC installers, which will continue to exist independently).

Otherwise, we'll have yet another player in the Haskell installer ping pong,
with every update of any installer undoing what every other installer has
done before.

>   4. Adds $INSTDIR/ghc-$GHC_VERSION/bin, $INSTDIR/extralibs/bin
>   and $PROGRAMFILES/Haskell/bin to PATH (optional)
>
>   5. Stores GHC's location in registry (optional)
>
>   6. Creates and registers the uninstaller (optional)
>
> The standard mode includes items 1-6, while the "just unpack"
> mode includes only 1 and 2. You can also select any of items 3-6
> individually.

Not to be misunderstood: this sounds quite promising, especially the
"(optional)" but bugs have had subtle causes in the past, so I'd like a
clear and detailed specification, something like the above, and it should
be linked from the HP release page, right next to the location of the HP
installer.

And, preferably, the Haskell installers should stop fighting each
other on my machine!-)

> If you want more details, you can read the source:
>
> http://github.com/23Skidoo/haskell-platform-windows/
>
> (the main source file is Nsisfile.nsi)

Thanks, that is almost readable. So you're actually removing
the $PLATFORMDIR explicitly from package.conf, and the
filetype associations seem to follow the current ghc installer's
ideas? Neil, are you listening?-)

If I read this correctly, it still doesn't follow the conventions we have
tried to agree on for years, and will not cooperate with, eg, WinHugs,
or previous settings. See separate answer to Duncan's question in this
thread for details and examples that illustrate what I mean by installer
ping pong.

>> what happens to existing settings,
>
> File associations are not currently backed up, though the
> uninstaller won't delete them if they weren't modified during
> installation.

So I'd lose them in the standard installation mode.

>> how does the installer integrate with existing installations of
>> GHC, Cabal, WinHugs, ...?
>
> Haven't tested. If you want to be absolutely safe, use the "just
> unpack" mode for now.

Good to have it!-)

>> 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"
>
> I think that third-party C libraries will be included in some
> form in the next versions, but for now it was decided to leave
> glut32.dll out.

You're already including part of the same third-party C library,
namely glut.h. So you're deliberately breaking the package you're
installing by removing an essential component, and you're not even
including that missing component, so your users will have to hunt for
it on the web. Not my choice, not a decision I can understand, but
not my decision to make.

Claus