[Hackage] #469: Support relocatable packages

[Hackage]

#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