>> > ($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 _______________________________________________ Haskell-platform mailing list [email protected] http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
