Add a vcvars32.bat-like bat file

[refold]

To make it easier to use several HP versions installed on the same machine, there should be a convenient way to temporary modify the environment to make a specific HP version the default. If you have used Visual Studio, then vcvars32.bat is what I have in mind. Bulat also suggested adding a GUI tool for this. This ticket depends on #63.

[claus]

if you're using cygwin's bash (actually, a slight variation should work with unix/bash as well), you can do something like the following in your ~/.bashrc (might need tweaking, this version assumes that there is a ghc/ghc-<version>/bin in your PATH that you want to replace, and that your GHCs are installed in c:/ghc/ghc-<version>):

function set-ghc { export PATH=`echo $PATH | sed 's/ghc\/ghc-[0-9.]*\/bin/ghc\/'$1'\/bin/'`; }
function F { i=0;
             for f in /cygdrive/c/ghc/$2*; 
             do COMPREPLY[$i]=`basename $f`; 
                i+=1 ; 
             done; }
complete -F F set-ghc

Calling set-ghc 6.10.3 replaces the in-PATH GHC, and function F is used to provide commandline completion for set-ghc, based on the currently installed GHCs.

Oh, and of course I have several GHCis in my right-click menu, as "Open with GHCi <version>", so the above doesn't need to replace the system-wide PATH.

Then one only needs to be able to go directly to the docs matching the currently selected GHC, which I can do from within GHCi, via `GHC.Paths` (not yet included in HP:-(, or from within Vim, via the haskellmode plugins.

[refold]

Adding ghc-paths at its current state to HP would be useless, since it refers to the paths on the build machine, not the machine on which HP is installed.

[claus]

Adding ghc-paths at its current state to HP would be useless, since it refers to the paths on the build machine, not the machine on which HP is installed.

By the nature of ghc-paths (capture the GHC installation paths in a Haskell module), you cannot bundle an installed version. That doesn't mean you couldn't install a bundled version, though!-) That is what post-install scripts are for, usually (call cabal install on a local copy, at the end of the HP installation).

I'm not saying it should be added - on its own, it is easy enough to install from hackage. The point is that it was designed to simplify a whole class of installation path related issues, so having it available for installation might be very useful (and better than reinventing its functionality).

This ticket is but one example of how it might make your job easier to have it at hand: I just install ghc-paths with every GHC I install, and if I have the path to ghc.exe, I can find everything else for that version (ghc-pkg.exe, libdir, docs), so I only have to worry about changing one path (and using a different GHCi with an absolute path works just as well).

As I said, just a suggestion.

[refold]

It would be a bit more tricky than just calling cabal install (we can't assume a working Internet connection), but doable. More serious problem with ghc-paths in its current form is that including it would again make the HP directory non-relocatable.

[refold]

Milestone 2009.4.0 deleted

[MtnViewMark]

Milestone 2010.4.0.0 deleted

[refold]

A better idea is to just ship MSYS and put a shortcut to it from the program menu. This will provide an environment in which the user can build libraries with C sources and Build-type: Configure.