GHC.Paths

[Claus Reinke]

> So you're assuming that, when shipping an executable linked against
> ghc-paths, that the target machine also has the ghc-paths library
> installed.  For ghc-paths that might be a fair assumption, because 
> someone wanting to know about GHC's paths presumably needs 
> GHC to be installed. (in general it's not a fair assumption, but that's 
> off topic now, so I'll not digress).

In general, I'd hope the data-files path to be relative to (and the
data-files included in) the package being shipped, but you're right, 
that wouldn't work with ghc-paths (or other packages that
provide access to local configuration info).

I realize now that you're trying to solve a more general problem
than the one I was looking at, and for which the extra data-files
indirection doesn't buy much:

The appeal of ghc-paths to me is that I can use one GHC api client 
*source*, and each GHC I build it with knows how to point to its 
own library path (similarly for GHCi and ghc-pkg scripting), by 
letting its own ghc-paths look up those paths in its own datadir (I
have to compile the client once on each machine, after which the
data-files indirection would allow to move the ghc installation). 

That does not help with shipping GHC api client *executables*, 
though, unless the data-dir of the locally installed ghc-paths happens to 
match the location of the one on which the client was built.. (eg, on 
windows, Cabal will not move datadir from its default location even
when configure uses --prefix=; so you'd have to move it explicitly;
and a windows executable is only going to run on windows)

(unless the data-file location for ghc-paths is standardised - and 
then, how to distinguish per-ghc-version ghc-paths packages?)

(or unless the client executable ships with its own libghc, to which
its own ghc-paths package could point?) 
 
> So using a data file doesn't solve the problem caused by static linking, 
> it just moves it to another place.  Dynamic linking is the only way to 
> fix this, and then the data file is unnecessary.

Doesn't dynamic linking have similar issues? Unless the location 
*and name* (including version) of the ghc-paths package is 
standardised, how do you ship a dynamically linked GHC api 
client executable and hope that the dynamic linker will find the 
ghc-paths package (you might just as well try to link libghc
dynamically, right?)?

That brings up the whole funny business of linker options
linker environment variables (-L,-rpath, LD_RUN_PATH,
LD_LIBRARY_PATH, ..), and their various failure modes.

Isn't it always going to come down to a question of
suitable conventions for one location, from which every
other information is then bootstrapped?

Claus

ps. on the third hand, cabal/hackage makes shipping source
    the default option for Haskell these days, right?