Thinking about what's missing in our library coverage
Axel.Simon at ens.fr
Fri Aug 7 10:20:51 EDT 2009
On Aug 7, 2009, at 10:58, Simon Marlow wrote:
> On 06/08/2009 12:59, Duncan Coutts wrote:
>> On Tue, 2009-08-04 at 12:02 +0100, Simon Marlow wrote:
>>> On 04/08/2009 00:59, Ian Lynagh wrote:
>>>> On Mon, Aug 03, 2009 at 04:44:32PM -0700, Donald Bruce Stewart
>>>>> How would you identify the top, say, 5 libs to add?
>>>> I would not look for libs to add. I would wait for people to
>>>> come and
>>>> tell me that they think that particular libs are worthy of
>>>> addition, and
>>>> then decide whether or not I agree.
>>> Ok, to kick things off then, I propose the following:
>>> * binary
>>> * getopt
>>> * gtk2hs
>> Now that's just crazy-talk! :-)
>> What/where is getopt? It's not on hackage. Elsewhere we've raised our
>> concerns about binary. gtk2hs is of course not cabalised.
> What is stopping gtk2hs being cabalised at this stage? Is it just
> work, or does it need extensions to Cabal?
I'm no Cabal expert, so Duncan might know more. What Gtk2Hs needs is
the ability to depend on executables (tools like a modified c2hs)
that are built by other Cabal packages. Furthermore, we need to
generate .hs files using these tools. I don't know how difficult it
is to use Cabal to generate the dependencies and invoke the right
tools. For instance, a file like .chs.pp is translated to .chs using
CPP or hscpp, then to .hs and .chi using our own c2hs and then it is
compiled using ghc. Finally, it seems that we need file-specific
options in order to compile certain files. I think Cabal has no
mechanism for that.
I'm sure it's all doable so it probably boils down to a lack of time :-)
More information about the Libraries