> > cabal install alex happy ansi-terminal mtl shake QuickCheck >> > > It likely won't be that simple due to versioning issues. It's entirely > possible that GHC will work only with certain versions of some of these > libraries (and not necessarily the latest ones), so the build may fail at > certain times and under certain conditions for some users.
This is exactly why I added build.stack.sh to shaking-up-ghc, to mitigate these kinds of issues. https://github.com/snowleopard/shaking-up-ghc/blob/master/build.stack.sh Personally, I think the shake build system should default to stack because it is the best way to get consistent builds. On Tue, Jan 26, 2016 at 2:33 AM, Simon Marlow <[email protected]> wrote: > > > On 23 January 2016 at 21:17, Andrey Mokhov <[email protected]> > wrote: > >> Herbert, >> >> > I think it's already quite convenient. After all, you're expected to >> > have a minimum GHC bootstrapping environment anyway. So having the >> > tools installed (as already do now, e.g. you need alex, happy, and >> > ghc to be able to work on GHC). >> >> I agree. Roughly, we are talking about going from: >> >> cabal install alex happy >> >> to: >> >> cabal install alex happy ansi-terminal mtl shake QuickCheck >> > > It likely won't be that simple due to versioning issues. It's entirely > possible that GHC will work only with certain versions of some of these > libraries (and not necessarily the latest ones), so the build may fail at > certain times and under certain conditions for some users. The configure > script will already have to check for compatible versions, like it does for > alex/happy. That's the reason we bundle things, it reduces the possibility > for failure. > > It's a complicated tradeoff, but if the GHC build system became tightly > coupled to Shake in the way that it is with Cabal, then bundling would > probably be the right thing to do. > > Cheers, > Simon > > >> This doesn't look too onerous (although one could also consider >> somehow packaging these dependencies together). And hopefully >> upcoming cabal features will make this more robust. >> >> Tuncer, >> >> > My suggestion, and what I'd expect, is to make Shake part of >> > GHC's included lib, just like process or xhtml. >> >> This sounds like a very big decision which is beyond the Shaking >> up GHC project. (I wouldn't want to shake up GHC too much!) >> >> Cheers, >> Andrey >> >> > -----Original Message----- >> > From: Herbert Valerio Riedel [mailto:[email protected]] >> > Sent: 23 January 2016 17:14 >> > To: Andrey Mokhov >> > Cc: [email protected]; GHC developers >> > Subject: Re: [ANNOUNCE] Shaking up GHC >> > >> > On 2016-01-23 at 14:05:56 +0100, Andrey Mokhov wrote: >> > >> Are there any plans as to how to include it in the GHC tree? Does it >> > >> ship with all the libraries required to build the build system, will >> > we >> > >> have a mini-build system to bootstrap it? If I recall correctly, we >> > rely >> > >> on Cabal sandboxes on Linux/OSX and global Cabal library >> > >> installations on Windows in order to run it. >> > > >> > > The simplest way is to add the 'shake-build' folder to the GHC tree >> > and >> > > ask first adopters of the new build system to globally install the >> > > dependencies (ansi-terminal, mtl, shake, QuickCheck). Then 'build.sh' >> > > and 'build.bat' scripts should work. >> > > >> > > I am open to suggestions on how to make this more convenient and >> > > robust. I've never used anything more advanced than a global cabal >> > > installation, so I'd appreciate input from more experienced users. >> > >> > I think it's already quite convenient. After all, you're expected to >> > have a minimum GHC bootstrapping environment anyway. So having the >> > tools >> > installed (as already do now, e.g. you need alex, happy, and ghc to be >> > able to work on GHC). >> > >> > And the new cabal nix-store feature to show-case as tech-preview >> > together with GHC 8.0 makes this even more robust by avoiding pkg-db >> > breakages due to reinstalls, which would be the main reason not to >> > rely on "global installed dependency". >> > >> > The shake-build.sh script simply needs to invoke `cabal new-build` to >> > generate the ghc shake build-tool executable. >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
