ghc/haskell tool registry
claus.reinke at talk21.com
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
>> - knowing your version would be sufficient to find
>> all the tools from your bundle
>> - finding all available haskell tools would be easy
>> - 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.
>> ----- Original Message ----- From: "Simon Marlow"
>> <simonmarhaskell at gmail.com>
>> To: "Christian Maeder" <Christian.Maeder at dfki.de>
>> Cc: "Manuel M T Chakravarty" <chak at cse.unsw.edu.au>; "GHC List"
>> <glasgow-haskell-users at haskell.org>
>> 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?
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users