GHC.Paths

[Simon Marlow]

Claus Reinke wrote:
>>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths-0.1.0.1 
>>>
>>
>> We discussed this on IRC recently, and the options we came up with were:
> 
> #ghc? are there logs for this channel, similar to 
> http://tunes.org/~nef/logs/haskell/ ?
> 
>> * Simon's ghc-paths package
>>
>> Pro: With dynamic libraries, you can move a binary to a different
>>     machine (with GHC in a different place) and it will work
>> Con: Needing to compile it on installation
> 
> a slight variation would be to have Setup.hs write the paths to
> a ghc-paths data-file, from which GHC.Paths could read them
> (no dynamic linking required: on updating the package, old linked 
> versions would read the new data-file).

Cabal has support for applications that come with data files (via the 
Paths_foo.hs mechanism) but not for *libraries* that come with data 
files, for good reasons: every client of the library would have to ship 
with the data file, install it, and be able to find it at run time.

> but i can't seem to get Cabal 
> data-files to work (symbol not found errors, iirc).

submit a bug report?

> the other options seem less attractive somehow.

So I don't much like the other options either, for the reasons that Ian 
gave as cons.

One way to avoid having to compile ghc-paths at install time is as 
follows (blame Duncan Coutts for this suggestion): use binary-patching 
on the library file to fill in the appropriate paths.

Cheers,
	Simon