[Haskell-cafe] Re: cabal install on Windows

[Duncan Coutts]

On Mon, 2009-11-09 at 16:02 +0000, Michael Fan wrote:
> I figured it out. It appears to be "Colour" package specific.
> The datadir still point to "c:\Program File" even with --user.
> I manually edit the dist/setup-config and get Colour installed.
> After that, other packages seem working fine.

>From the ticket:
http://hackage.haskell.org/trac/hackage/ticket/466

        On Windows the --datadir is set independently of the --prefix
        (at least for libraries). This is actually quite annoying
        because it's not discoverable and when you do discover it you've
        got to set the datadir along with the prefix on the command line
        or in the config file.
        
        The problem is to do with relocatable packages and data files.
        
        Suppose you have a library that has data files. For a
        hypothetical example how about some Unicode library that uses
        data files of character traits. Now we want to use that library
        in a program and we want to have that program be relocatable.
        That means that at runtime the library needs to be able to
        locate its data files. But the place where the library was
        installed is completely independent of where the .exe is being
        run from.
        
        One way to make this appear to work is for the library data
        directory to not really be relocatable, then it looks like we
        can relocate the .exe and have it still work. Of course the .exe
        is not very re-locatable, in particular it cannot be relocated
        to another machine. This is often the use case for relocatable
        packages on Windows.
        
        Perhaps another solution would be to place the burden of finding
        the data files on the executable, or at least on the process of
        preparing the relocatable executable. If we made the process of
        generating a relocatable package more explicit we could include
        in that process checking for dependent library packages that use
        data files. We could then inform the packager and/or copy/link
        the necessary data files into a place where the library code
        will be able to find them relative to the executable. See #469.