Changes to GHC that will expose new packages

[David Terei]

On 23 March 2012 00:55, Magnus Therning <magnus at therning.org> wrote:
> On Mar 23, 2012 7:25 AM, "David Terei" <davidterei at gmail.com> wrote:
>>
>> So do we have any proposal for a way forward here? seems the options now
>> are:
>>
>> 1) Include mtl, haskeline, terminfo, utf8-string. Mark as hidden all
>> except mtl.
>>
>> 2) As above but rename all except mtl to be ghc-*
>>
>> 3) Discuss including packages that provide functionality equivalent to
>> above packages in haskell platform, rework ghc code to depend on those
>> instead, include all packages and expose them.
>>
>> 4) Fix cabal / ghc to allow ghc to depend on packages and have them
>> remain truly internal
>>
>> I'd be happy with any of the first 3 and particularly the first 2 as
>> it minimizes the work i need to do. Long term 4 seems to be the right
>> approach.
>
> Just to make sure it's explicit. Does this mean that breaking out GHCi to a
> seperate package isn't an option?
>
> If so, would it be possible to hear why?

That is what I'm doing. In the GHC source tree GHCi is already its own
package but it only includes executables, so its package dependencies
aren't an issue. I'm changing it to also expose a library as I want to
expose an API.

Now we could technically make this changed package a *new* package
separate from the rest of GHC. However this would involve simply
copying the code. So we would have an ongoing maintenance issue of
keeping the code bases in sync. So yes, this is an option but an ugly
one from a software engineering point of view. There are ways we could
do build script hackery to mean we wouldn't need to copy the code I
guess. The GHCi package will be very specifically tied to a version of
GHC though.

Put this as option 5). Maybe it is the nicest / easiest solution until
we have a proper way to handle internal packages.

Cheers,
David

>
> /M