Hi,

First, in my experience, there is no "normal" here. Here's few popular options. And thats the problem :)

For well-known programs, registry keys. HKCU/Programs/Foo/InstallDir=c:\Foo or something like that (exact path is something a bit more complex) Thats not great, esp since Haskell programs are in general not registry aware.

Visual studio adds environment variable like: VS80COMNTOOLS=C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\ which is easy to expand to right directories if you know the way toolset if organised. It is a great idea, to certain extent. It's maybe right way for compilers, but for other programs like alex...it might be confusing. Again, this causes much pain, to me.

their installation directory in PATH. I find the automatic addition to PATH disgusting for devel environment, it tends to lend a hand for lazy devels that then forget what they need, which easily results in non-reproducible environment. I'd say its ok if Haskell adds one single entry to the PATH, for all cabal installed programs. That I can live with.

The good and bad of each are as follows: 1) Move alex.exe into some global Haskell directory for binaries (which is on the PATH) Not too bad, but while names might not clash, if too Cabal programs both have LICENSE in their same directory, and both read it, things go wrong. The whole issue is that name uniqueness goes. 2) Make an alex.bat in some global Haskell binary directory (on the PATH) Again, quite workable. There are a few disadvantages, the app isn't real, so certain things don't always work exactly like they should - for example Ctrl-C will ask "do you want to terminate the batch file" - not just kill Alex. 3) Make Cabal detect wherever it puts alex, so it can then use it. Good, and at a very minimum, Cabal should detect where it put something. It could even keep an installed tools database, if it felt the need. The disadvantage is you then can't invoke Alex/Haddock etc at the command line, which is useful to have. 4) Put whereever it puts alex on the PATH. I hate this one as much as Esa does. Thanks Neil

Hi,

prefix = c:/Program Files bindir = $prefix/Haskell/Tools datadir = $prefix/$pkgid

Looks good! The MS Spec is that it should be Program Files\<Company Name>\<Program Name>, so for this I'd suggest: bindir = $prefix/Haskell/bin datadir = $prefix/Haskell/$pkgid It also means that people can find all their Haskell programs with greater ease, any package management thingies can find all Haskell programs. It also clutters up the Program Files directory less. But the basic concept of shoving all bin files in one directory and data files in another is great! Thanks Neil

"Neil Mitchell" writes: (snip)

The good and bad of each are as follows:

1) Move alex.exe into some global Haskell directory for binaries (which is on the PATH) Not too bad, but while names might not clash, if too Cabal programs both have LICENSE in their same directory, and both read it, things go wrong. The whole issue is that name uniqueness goes.

The .exe should get installed in a different location than something like a README, right?

2) Make an alex.bat in some global Haskell binary directory (on the PATH) Again, quite workable. There are a few disadvantages, the app isn't real, so certain things don't always work exactly like they should - for example Ctrl-C will ask "do you want to terminate the batch file" - not just kill Alex.

3) Make Cabal detect wherever it puts alex, so it can then use it. Good, and at a very minimum, Cabal should detect where it put something. It could even keep an installed tools database, if it felt the need. The disadvantage is you then can't invoke Alex/Haddock etc at the command line, which is useful to have.

Executables that cabal installs shouldn't just be available to cabal, though! Haskell is good for stuff besides building Haskell ;) peace, isaac