Changes to GHC that will expose new packages

[Magnus Therning]

On Fri, Mar 23, 2012 at 09:11:33AM -0700, David Terei wrote:
> 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.

First of all I'm not suggesting that you make any changes to how
ghc/ghci is *developed*, you keep doing that in whatever manner you
see fit.  What I am suggesting is that the distribution of the
source packages is separated, i.e. that ghc sources come in one
tar-ball and ghci sources in another.

The ideal situation, for me as a distro packager, would be if I could
do the following:

1. Download, build and install ghc (without ghci)
2. Download (from Hackage), build and install all deps for ghci 
3. Download (from Hackage), build and install ghci

It sounds like you might be moving in that direction.

Tying ghci to a specific version of ghc ought to be possible to do
using dependencies in ghci's CABAL file, right?

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

If you do go this way, why would you ever want to go in the direction
of using internal packages?

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus

I invented the term Object-Oriented, and I can tell you I did not have
C++ in mind.
     -- Alan Kay
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://projects.haskell.org/pipermail/haskell-platform/attachments/20120323/8759b743/attachment.pgp>