#466: datadir does not follow prefix on windows (for libs) ----------------------------+----------------------------------------------- Reporter: duncan | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.8 Component: Cabal library | Version: 1.6.0.1 Severity: normal | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.3 | Platform: Windows ----------------------------+----------------------------------------------- Changes (by duncan): * difficulty: easy (<4 hours) => normal * summary: libdir does not follow prefix on windows => datadir does not follow prefix on windows (for libs) Old description:

On Windows, for some reason, the `--libdir` is set independently of the `--prefix`. This is actually quite annoying because it's not discoverable and when you do discover it you've got to set the libdir along with the prefix on the command line or in the config file.

Apparently there was some reason why it is done this way. We should find out what that reason is and determine if it is valid and if so if there is any way to make it work in a less annoying way.

If we think it will not break anything then changing the default is trivial.

New description: 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. Comment: I was remembering this wrong, it's the datadir not the libdir. Updated the description. Filed ticket #469 for better support for relocatable packages. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/466#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects