On Fri, Mar 23, 2012 at 02:08:41PM -0700, David Terei wrote: > On 23 March 2012 12:19, Magnus Therning <mag...@therning.org> wrote: >> 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 > > This is an orthogonal issue. I'm saying I want to increase the deps > needed for ghci. Now making ghci and ghc separate components from a > package managers point of view doesn't change this in a meaningful > way. Sure you could just not grab the ghci component and you wouldn't > be hit by the new deps, but the Haskell Platform I imagine will always > want to bundle up both ghc and ghci. They are aiming for ease of use > and installation after all. So the Haskell Platform still ends up > pulling in the extra deps, which is the issue.
I'm sorry, but I don't see the orthogonality. I see no difference between HP and other packagers; we all are in the business of providing GHC and a choice of tools and libraries. To be a bit blunt: HP is a package of Haskell for platforms with poor package managers (read Windows). I don't think any packager would ever consider *not* including GHCi. Adding specific versions of Haskell packages to GHC means that *all* packagers are tied to those versions. I may be wrong, but I don't think the following is possible with the GHC sources today: 1. Build and install *only* the compiler and its libraries (i.e. *not* including GHCi) 2. Build and install *only* GHCi, using an already installed GHC and libraries That would be the kind of separation I'm arguing for. Separate source distribution would be one way to ensure that. A changed build system would be another way. Once that is possible GHC can include any libraries, because as a packager I can choose not to use them (though in some cases patching may be necessary). >> If you do go this way, why would you ever want to go in the >> direction of using internal packages? > > In the situation we have the possibility of splitting out the code > from the main ghc code base. However, what happens when GHC proper > wants to depend on some new packages? Every time the GHC developers > want to make this decision we can't make it in isolation as it means > the Haskell Platform is affected. > > Basically, GHC tried to get out of the packaging game but hasn't > actually managed to do that. Allowing GHC to decide what packages to > use and what version in isolation is a worthy goal that hasn't been > realized. True, but wouldn't it then be better to make the build system more modular? /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
pgpCaMYSwAlaH.pgp
Description: PGP signature
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
