On Thu, Jan 1, 2015 at 6:42 PM, Herbert Valerio Riedel <hvrie...@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
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
