On 23 March 2012 15:12, Magnus Therning <mag...@therning.org> wrote: > 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)
So maybe I'm missing something here as I'm not familiar with the issues involved with packaging GHC. But don't you need to have GHC when installed include a bunch of libraries that it depends on like ByteString, Hoopl... ect? Separating out GHCi won't change that situation. > 2. Build and install *only* GHCi, using an already installed GHC and > libraries OK sure. Now any user (which is all users basically) that want to use GHCi will end up with a specific version of Haskeline, utf8-strings, terminfo and mtl on their system. Given the end result for users is the same and I thought that was the point here this is why I think what you are proposing is orthogonal. I'm most likely at this stage just going to create a copy of sorts of the code I need and put it in a package on hackage with very specific ghc version dependency. > > 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 _______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
