GHC.Paths

[Simon Marlow]

Claus Reinke wrote:
>
> 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.

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

There's another problem though, which you mentioned: datadir.  The 
datadir you used when you installed ghc-paths on your machine might not 
be the same as the datadir used when ghc-paths was built on the target 
machine.  So you take the binary to another machine, and the ghc-paths 
there might be configured with a different datadir => fail.  Environment 
variables are not a good way to fix this.

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.

Cheers,
	Simon

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