On Fri, Mar 23, 2012 at 09:11:33AM -0700, David Terei wrote: > 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.
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: mag...@therning.org jabber: mag...@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
pgphscZaMKcL5.pgp
Description: PGP signature
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
