Windows build gotchas

[Martin Foster]

On Thu, Jan 1, 2015 at 6:42 PM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

>
> > I noticed that the cabal output made reference to
> > "C:\Users\Martin\AppData\Roaming\cabal\", so tried moving that out of the
> > way, but it only made the problem worse. I did figure it out eventually:
> in
> > addition to that directory, "%APPDATA%\cabal", there were also files left
> > over in "%APPDATA%\ghc". Once I removed that directory as well, things
> > started working again - but it took me a lot of time & frustration to get
> > there.
>
> That's btw because Cabal/GHC uses `getAppUserDataDirectory "cabal"` and
> `getAppUserDataDirectory "ghc"` respectively...
>
>
Hrm. It seems the behaviour of getAppUserDataDirectory is decided at
compile-time, by way of `#if defined(mingw32_HOST_OS)`:


http://hackage.haskell.org/package/directory/docs/src/System-Directory.html#getAppUserDataDirectory

So, given the "build GHC on Windows" procedure involves downloading Cabal
as a binary, it could only be changed by using a different binary. And much
as I might be able to argue it'd make sense for getAppUserDataDirectory to
use $HOME instead of %APPDATA% when in MSYS, changing it would be a
backwards-compatibility-breaking change to System.Directory.

Well, I suppose, theoretically, it could do something like... use the value
of some special environment variable if it's set at runtime, otherwise
retain the existing behaviour. But that doesn't feel like it'd be good
practice to me - too hacky.

So I guess that'll be staying as it is, then.

Good to know why it's like that, though - it makes a lot more sense now.
Thanks for the pointer!

- Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20150103/02929c57/attachment.html>