GHC.Paths

[Claus Reinke]

> This is what you were asking for, I think:
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghc-paths-0.1.0.1
>
> $ ghc -e "GHC.Paths.libdir"
> "/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.8.3"
> $ ghc -e "GHC.Paths.ghc_pkg"
> "/home/simonmar/fp/bin/x86_64-unknown-linux/ghc-pkg"

[you have an unversioned ghc-pkg path?]

Yes!-) That is going in the right direction. With something like this,
I can now define GHCi commands like:

    :def ghc_pkg \l->return $ ":!"++GHC.Paths.ghc_pkg++" "++l
    :def browser \l->return $ ":!c:/Progra~1/Opera/Opera.exe "++l
    :def users_guide \_->return $ ":browser "++GHC.Paths.libdir++dropWhile 
(/='/')GHC.Paths.docdir++"/index.html"

(is there a saner way to handle the $httptopdir prefix in GHC.Paths.docdir?)
and have them do the right thing in every GHCi for which ghc-paths is installed:

    Prelude> :ghc_pkg list
    c:/ghc/ghc-6.9.20080514\package.conf:
        Cabal-1.5.1, GLUT-2.1.1.1, HUnit-1.2.0.0, OpenGL-2.2.1.1,
        QuickCheck-1.1.0.0, Win32-2.1, array-0.1, base-3.0, bytestring-0.9,
        cgi-3001.1.6.0, containers-0.1, directory-1.0, fgl-5.4.1.1,
        filepath-1.1, (ghc-6.9.20080514), ghc-paths-0.1.0.1, ghc-prim-0.1,
        haskell-src-1.0.1.1, haskell98-1.0.1, hpc-0.5, html-1.0.1.1,
        integer-0.1, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0,
        old-time-1.0, packedstring-0.1, parallel-1.0.0.0, parsec-2.1.0.0,
        pretty-1.0, process-1.0, random-1.0, regex-base-0.72.0.1,
        regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, stm-2.1.1.0,
        template-haskell-2.2, time-1.1.2.0, xhtml-3000.1.0.0

    Prelude> :users_guide
    -- fires up a browser with the users guide for *this version* of GHCi

and similarly for GHC API clients. Once ghc-paths stabilizes and
can be relied on to exist in GHC installations, it will also help to
simplify my haskellmode plugins for Vim (and other such IDEs
which provide direct access to Haddocks).

> Now I realise there are various ways in which this could be improved, not least of which is that 
> it could come with GHC rather than having to be installed separately.  But I put it up mainly for 
> comments and to provoke discussion about whether this is really the way we want to do it.  As a 
> nice side-effect it should be useful right now to people using the GHC API.
>
> Cons that I can think of:
>
>  - it needs to be configured/built/installed when GHC is installed, which
>    is inconvenient (e.g. a Windows install just copies files, normally)

This could perhaps be done when the installed GHC is first run (or
manually, before GHC.Paths is first used). In any case, having to do
this once per GHC (re-)installation is a big improvement over having
to search for these things for every client invocation (also a better
chance of getting it right, I assume).

>  - we can't use this for GHC itself, without dynamic linking

one more incentive for dynamic linking?-)

>  - the implementation is hacky (but we could make it less hacky if it
>    were part of the GHC install).

- in Setup.hs, I had to make this little change to escape "\\"s:

      let buildinfo = emptyBuildInfo{
               cppOptions = ["-DGHC_PATHS_GHC_PKG=" ++ show ghc_pkg,
                             "-DGHC_PATHS_GHC=" ++ show ghc,
                             "-DGHC_PATHS_LIBDIR=" ++ show libdir,
                             "-DGHC_PATHS_DOCDIR=" ++ show docdir ]
             }

- since every release of ghc tends to come with a new cabal:
    how stable is this Setup against the cabal api changes?

> Pros:
>
>  - with dynamic linking this would be very useful - it would enable
>    portable binaries dynamically linked against the GHC API.
>
>  - it's a convenient API
>
> Cheers,
> Simon

Thanks,
Claus