#469: Support relocatable packages ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.6.0.1 Severity: normal | Keywords: Difficulty: very hard (<1 week) | Ghcversion: Platform: | ----------------------------------+----------------------------------------- This is both useful and doable on both Windows and Unix systems. We already have limited support for relocatable (also sometimes called prefix-independent) packages on Windows. Specifically, a relocatable package is often what people want when they want to prepare a package for redistribution, especially on Windows for use with an installer. What is required is that an exe and all supporting files (data files and potentially also other shared libs) exist together in one directory hierarchy and that that directory can be placed anywhere in the filesystem and the exe will still be able to find all its associated support files. There are some restrictions on preparing a relocatable package. In particular the user must configure it such that all install directories for the various kinds of files (libdir, datadir etc) are relative to the `$prefix`. Configuring a relocatable package should be something that is done explicitly. At the moment it is done simply by configuring it in the right way, but Cabal is never aware that the user is trying to construct a relocatable package. If it is explicit then we can take different actions if necessary (as it is on unix) and do additional checks. So a configure option `--relocatable` or something should be used. Installing a relocatable package is somewhat of an exception because it involves using a prefix which would otherwise be empty. Creating an image for a relocatable package would use a empty `$prefix`. The tricky issues that have to be addressed are: * data files for the program itself * data files in library dependencies * shared libraries The mechanism for finding data files at runtime is the `Paths_pkgname` module that Cabal generates. On Windows this can make use of the Win32 api that lets a .exe program discover where it was run from. On unix there is no reliable equivalent but the next best alternative is to use wrapper scripts to set environment variables before running the real program. This mechanism can work pretty well for data files that belong to the executable. It is rather harder for data files in dependent packages (see #466). One option would be to copy the data files belonging to dependent packages and install them along with the executable (checking for clashes). This would involve being able to locate the data files of installed libraries which would require extending the data stored for installed packages. Libraries that require data files are relatively rare (though this should be checked) so this feature could be punted for an initial version. In future there will also be the issue of shared libraries to consider. That is, when Haskell implementations can produce Haskell libs as shared libraries. This complicates the construction of relocatable packages. Again the approach taken on Windows and Unix will have to be different. On Windows it will be possible to copy the .dll files into the same directory as the .exe file (or a subdir if using .manifest files). On Unix a wrapper script using `LD_LIBRARY_PATH` will probably be necessary. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/469 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects