[ANNOUNCE] Shaking up GHC

[Joe Hillenbrand]

>
> 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 <marlowsd at gmail.com> wrote:

>
>
> On 23 January 2016 at 21:17, Andrey Mokhov <andrey.mokhov at newcastle.ac.uk>
> 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:hvriedel at gmail.com]
>> > Sent: 23 January 2016 17:14
>> > To: Andrey Mokhov
>> > Cc: dluposchainsky at googlemail.com; 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
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160126/c9540313/attachment.html>