ghc/haskell tool registry

Claus Reinke claus.reinke at
Tue Nov 20 09:16:36 EST 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.


> 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"
>> <simonmarhaskell at>
>> To: "Christian Maeder" <Christian.Maeder at>
>> Cc: "Manuel M T Chakravarty" <chak at>; "GHC List"
>> <glasgow-haskell-users at>
>> 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:
>>>>> On Sat, Nov 17, 2007 at 03:02:55PM +0000, C.M.Brown 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
>>>>> 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 at
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at

More information about the Glasgow-haskell-users mailing list