GHC.Paths

[Claus Reinke]

>>> * 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.

Perhaps I'm misunderstanding something, but I see no reason why
the mechanism should be limited to executables, as long as the data
file location is baked in at library installation time (which seems to be
the case, with an optional environment variable override). It is the
library, not the client, that has to provide and find these data-files.

Here's my small experimental variation of ghc-paths, which
seems to work as expected:

------------------------------ modifications

$ diff -r ghc-paths-0.1.0.1/ modified-ghc-paths-0.1.0.1/
Only in modified-ghc-paths-0.1.0.1/: .ghc-paths.cabal.swp
diff -r ghc-paths-0.1.0.1/GHC/Paths.hs modified-ghc-paths-0.1.0.1/GHC/Paths.hs
4c4
<         ghc, ghc_pkg, libdir, docdir
---
>         ghc, ghc_pkg, libdir, docdir, programs
6a7,9
> import Paths_ghc_paths(getDataFileName)
> import Distribution.Simple.LocalBuildInfo(withPrograms)
>
13a17,22
>
> programs :: IO ()
> programs = do
>   pathsFile <- getDataFileName "paths"
>   paths <- fmap lines $ readFile pathsFile
>   mapM_ putStrLn paths
diff -r ghc-paths-0.1.0.1/Setup.hs modified-ghc-paths-0.1.0.1/Setup.hs
55,58c55,58
<                cppOptions = ["-DGHC_PATHS_GHC_PKG=\"" ++ ghc_pkg ++ "\"",
<                              "-DGHC_PATHS_GHC=\"" ++ ghc ++ "\"",
<                              "-DGHC_PATHS_LIBDIR=\"" ++ libdir ++ "\"",
<                              "-DGHC_PATHS_DOCDIR=\"" ++ docdir ++ "\"" ]
---
>                cppOptions = ["-DGHC_PATHS_GHC_PKG=" ++ show ghc_pkg,
>                              "-DGHC_PATHS_GHC=" ++ show ghc,
>                              "-DGHC_PATHS_LIBDIR=" ++ show libdir,
>                              "-DGHC_PATHS_DOCDIR=" ++ show docdir ]
60a61
>       writeFile paths $ unlines [ghc_pkg,ghc,libdir,docdir]
67a69
> paths = "paths"
Only in modified-ghc-paths-0.1.0.1/: ghc-paths.buildinfo
diff -r ghc-paths-0.1.0.1/ghc-paths.cabal modified-ghc-paths-0.1.0.1/ghc-paths.cabal
13c13
< build-depends: base
---
> build-depends: base, Cabal
16a17,19
> other-modules: Paths_ghc_paths
> data-files: paths
> extra-tmp-files: paths

------------------------------ trial run

$ cd modified-ghc-paths-0.1.0.1/

$ runhaskell Setup.hs configure --prefix=c:/ghc/libraries --datadir='$prefix'
Configuring ghc-paths-0.1.0.1...

$ runhaskell Setup.hs build
Preprocessing library ghc-paths-0.1.0.1...
Building ghc-paths-0.1.0.1...
[1 of 2] Compiling Paths_ghc_paths  ( dist\build\autogen\Paths_ghc_paths.hs, dist\build\Paths_ghc_pa
ths.o )
[2 of 2] Compiling GHC.Paths        ( GHC\Paths.hs, dist\build\GHC\Paths.o )
c:\ghc\ghc-6.9.20080514\bin\ar.exe: creating dist\build\libHSghc-paths-0.1.0.1.a

$ runhaskell Setup.hs install
Installing: c:/ghc/libraries\ghc-paths-0.1.0.1\ghc-6.9.20080514
Registering ghc-paths-0.1.0.1...
Reading package info from "dist\\installed-pkg-config" ... done.
Saving old package config file... done.
Writing new package config file... done.

$ cd ..

$ ghc -e GHC.Paths.programs
c:\ghc\ghc-6.9.20080514\bin\ghc-pkg.exe
c:\ghc\ghc-6.9.20080514\bin\ghc.exe
C:\ghc\ghc-6.9.20080514
$httptopdir/doc

------------------------------ 

So it would seem possible to go for this route, and clients linked
against an old version of ghc-paths would find the new ghc paths
as long as the location of the library itself (or rather, its datadir)
doesn't change on reinstallation of said library (and even then,
there's the ghc-paths_datadir environment variable, similar to
LD_LIBRARY_PATH & co).

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

see #306 - I was just missing Paths_package in other-modules.

Btw, I get the impression that cvs-libraries is not heavily
subscribed. Some will pick up your package from the hackage
RSS feed but if you'd like feedback on ghc-paths, perhaps
you could mention it in ghc-users (and is it really stable already?)?

Given that this little package has the potential to address a
wide range of issues (GHC API clients like Haddock2,
shim, .., tools/IDEs/GHCi users that need to find the right
ghc/ghc-pkg version, ..), I'd expect some interest!-)

Adding the man/-dir location would also resolve the
--full-help ticket., just as docdir almost solves the
--print-docdir issue (is there a platform-independent
system for filling in that $httptopdir variable?).

Claus