Remaining bugs in Cabal under Windows

[Simon Marlow]

On 16 August 2004 19:20, Krasimir Angelov wrote:

>      There still exists some bugs in Cabal when it is
> used under Windows.
> 
>    - The platform dependent places in the code are
> marked with #ifdef mingw32_TARGET_OS but this macro is
> never defined ever under Windows. You must add
> -Dmingw32_TARGET_OS to the command line while building
> setup.exe and also add -Dmingw32_TARGET_OS to
> options-ghc field in Setup.description.

I'll fix this.  Isaac: is it ok for me to commit fixes to the
repository?  I have a couple of other things I found when building Cabal
on Windows recently, and Krasimir has sent me a large patch to fix a
number of problems.

>    - When Cabal is used to build library package then
> it fails to find ar.exe in the path. This isn't a
> problem when in the build is run from cygwin or mingw
> environment but is painful on plain Command prompt.

Agreed - one of the goals of Cabal is that it should work with a plan
GHC installation, no cygwin required.  I think ar.exe should be packaged
with GHC in the same directory as ghc.exe, so that it'll be available in
the PATH.  This is easier than providing ar functionality from GHC
itself, which would perhaps be nice but is more work and is
GHC-specific, you still have to invoke ar for other compilers.

>    - The package uses (getEnv "HOME") to get the path
> to home directory. The variable isn't present in plain
> Command prompt under Windows.

Agreed.  I need to know the equivalent of $HOME for GHC too, so that GHC
can keep a per-user package database.

>    - The default installation prefix under Windows is
> "C:\Program Files" but it is known that some times GHC
> doesn't work very well with paths which have spaces. I
> don't know whether this can be fixed or this depends
> from gcc and ld

GHC itself doesn't have problems with pathnames with spaces in; GHC's
build system does, though.

I claim: it should be a goal to make everything work for pathnames
containing spaces.

>      To fix third bug I tried to use
> SHGetFolderPathAndSubDir function to retrieve the
> "Application Data" folder for current user.
> This is:
> 
> "C:\Documents and Settings\kr_angelov\Application
> Data"
> 
> on my PC. The trouble here is that to do that I need
> to add shell32 to extra-libs field in package
> description. I don't have a way to preprocess
> Setup.description so I can't add shell32
> conditionally.
> I would like to have a collection of functions like:
> 
> getCurrentDirectory

we already have that

> getAppUserDataDirectory
> getHomeDirectory

Maybe - although the conventions still differ between Unix and Windows.
On Unix, to store per-user data you would use <homedir>/.<app> whereas
on Windows you use <homedir>/<app>.  So I think the win32 library should
provide access to getAppUserDataDirectory, and the app code still needs
to be conditionally compiled.

Cheers,
	Simon