On 23 March 2012 00:55, Magnus Therning <mag...@therning.org> wrote: > On Mar 23, 2012 7:25 AM, "David Terei" <davidte...@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 _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
