On 24 August 2006 11:20, Henning Thielemann wrote:
On Tue, 22 Aug 2006, Simon Marlow wrote:
- A source tree can optionally be populated with more packages, which will be included in the build as normal. At the moment, the only packages you can add in this way are:
ALUT, HGL, HUnit, OpenAL, OpenGL, QuickCheck, X11, cgi, fgl, haskell-src, html, mtl, network, parsec, time, xhtml
because we're still using GHC's build system to build packages rather than Cabal. When we switch to using Cabal to build packages inside a GHC build, then it will be possible to populate the tree with any Cabal package.
Possibly we could also distribution an "extra libs" source bundle containing these packages.
Just a question: Will it still be possible to have an Haddock index of _all_ installed libraries without hassle? I know haddock supports this, but how easy will it be to achieve that?
Since the distributions we build with the nightly builds will have all the libraries, the Haddock docs in the distributions we ship will have complete integrated indices. This means that making a minimal distribution in a build tree that has everything is not just a matter of removing stuff, also the Haddock index must be rebuilt, and the package database needs to have the extra packages removed too. Thanks for reminding me about this! I'm not sure we'll ship minimal binary installers for 6.6 yet, it depends whether we get to it before the release date. Cheers, Simon
Hello Simon, Thursday, August 24, 2006, 2:40:55 PM, you wrote:
This means that making a minimal distribution in a build tree that has everything is not just a matter of removing stuff, also the Haddock index must be rebuilt, and the package database needs to have the extra packages removed too.
it seems that dividing ghc to the core and additional libs is dependent on cabalizing all those packages that are now distributed with ghc? so, situation is rather paradox - in order to strip some lib from ghc distribution because it don't used at all, one should cabalize it :) at least we can start by removing from ghc distribution large graphics/sound libraries that was already cabalized. are there such beasts? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin wrote:
Hello Simon,
Thursday, August 24, 2006, 2:40:55 PM, you wrote:
This means that making a minimal distribution in a build tree that has everything is not just a matter of removing stuff, also the Haddock index must be rebuilt, and the package database needs to have the extra packages removed too.
it seems that dividing ghc to the core and additional libs is dependent on cabalizing all those packages that are now distributed with ghc?
so, situation is rather paradox - in order to strip some lib from ghc distribution because it don't used at all, one should cabalize it :)
at least we can start by removing from ghc distribution large graphics/sound libraries that was already cabalized. are there such beasts?
All those packages are already Cabalized. Hugs uses Cabal to build all its libraries. As for whether all the Cabal scripts work propertly with GHC... I suspect there may be some hiccups, since we haven't tested that. Cheers, Smion
On Thu, Aug 24, 2006 at 12:22:05PM +0100, Simon Marlow wrote:
Bulat Ziganshin wrote:
at least we can start by removing from ghc distribution large graphics/sound libraries that was already cabalized. are there such beasts?
All those packages are already Cabalized. Hugs uses Cabal to build all its libraries. As for whether all the Cabal scripts work propertly with GHC... I suspect there may be some hiccups, since we haven't tested that.
I tested several of them with GHC some time ago. I'd expect all the fptools packages except base, readline and stm to work with Cabal+GHC, and those three are included in the proposed core. There may be glitches under Windows; the ones using configure will need to be built under MinGW. BTW, the minimal Hugs distribution has base, haskell98 and Cabal only.
participants (4)
-
Bulat Ziganshin -
Ross Paterson -
Simon Marlow -
Simon Marlow