Re: ghc/haskell tool registry

20 Nov 2007

      ...
registry sounds like overkill to me. If really an absolute hardcoded
path is needed, I would appreciate if it is stored only in a single
place (for ghc, ghci, ghc-pkg and package.conf).
that was my point: how do you find that 'single place',
given the wide variety of versions, platforms, packagers, 
installation-specific availability, ..?

the only half-way portable solution (without a special case 
for every platform) i can think of is a program in PATH.
we don't always keep all versions of ghc tools in PATH,
but we need one single tool "to bind them all"..;-)

as long as that tool can be found in PATH, it can serve
as a mediator/abstract interface for finding everything else, 
independent of platform.
...
Other tools have a "relocate" script, that only changes that location
after unpacking (or move).
think of 'ghc-tools' as the guardian for your 'single place' 
and of 'ghc-tools relocate' as your relocate script.

claus
...
Cheers Christian
Claus Reinke wrote:
...
may i suggest a different approach? most shells have commands to list
programs in PATH beyond the first match, such as 'whereis ssh', 'which
-a ssh', or 'type -a ssh'. now, this won't
help directly because the ghc tool in question might not be on
the PATH.
but as this issue is so widespread, one could extend one of the
existing haskell package registries (ghc-pkg, cabal) to cover
haskell tools as well. every haskell tool would know how to
register itself with its current location, and how to query the haskell
tool registry for the location of other tools (preferably from the same
build/version). since we're on the ghc list:
ghc-tools (un-)register <path>/ghc<version>
   ghc-tools list ghc<version>
   ghc-tools describe runhaskell
   ghc-tools field location ghc-6.9
   ghc-tools field user_guide ghc-6.9
   ..
pros:
- knowing your version would be sufficient to find
       all the tools from your bundle
   - finding all available haskell tools would be easy
downsides:
   - tools would have to register themselves after
       installation/relocation, and unregister during        uninstall
   - there is no single ghc-pkg/cabal instance to choose,
       but multiple versions..
the former is no worse than for packages, the latter
is a runhaskell-style issue: we want a single ghc-tools
in the path, but we don't care who provides it.
claus
----- Original Message ----- From: "Simon Marlow"

To: "Christian Maeder" 
Cc: "Manuel M T Chakravarty" ; "GHC List"

Sent: Monday, November 19, 2007 9:35 AM
Subject: Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)
...
Christian Maeder wrote:
...
Ian Lynagh wrote:
...
...
> Is there a way for GHC on OS X to find where it was run from, so
> that it
> can find package.conf?
The command:
ghc --print-libdir
should do it.
But the way that knows what to print on unix machines is that ghc is a
shell script wrapper which passes -B<libdir> to the real GHC binary. If
you want to be able to move GHC around then the wrapper can't have the
On Sat, Nov 17, 2007 at 03:02:55PM +0000, C.M.Brown wrote:
path hardcoded.
The wrapper could call `pwd` to find out the current path.
pwd gives you the directory that the script was invoked *from*, not
the directory in which the script resides.  This is a common problem
on Unix: there's no general way to find out the location of a binary.
Well that's not entirely true.  On Linux you have /proc/<pid>/exe, and
on Solaris you have getexecname().  Does MacOS X have anything?
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users