[ANNOUNCE] Shaking up GHC

[Tuncer Ayaz]

On 23 January 2016 at 14:05, Andrey Mokhov wrote:

> 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.
>
> Could you create a ticket on github suggesting possible
> approaches? I'm afraid our discussion may get lost in ghc-devs
> mailing list.

My suggestion, and what I'd expect, is to make Shake part of GHC's
included lib, just like process or xhtml.

Neil said this can be a maintenance burden, and I'm aware of that
argument, but the bundled libs ghc depends on are not maintained by
ghc devs and merely included as known-to-work versions to go with the
ghc release as well.

Why do I want this?

a1) Want to use Shake? Install GHC via OS pkg mgr or prebuilt binary
    tarball, and be done. This way, telling potential users migrating
    from Makefile(s) to Shake is as easy as "Install ghc-8.0". Anyone
    who needs a different Shake version can, as it's done right now
    with cabal(-install), install Cabal+cabal-install as a 2nd
    dependency. So, anybody that that wants to use Shake instead of
    make, can just install ghc itself. That's a very minimal set of
    requirements and steps, compared to installing Shake after first
    getting ghc.

a2) Like what Xmonad has done for custom window management, Shake can
    be that for build scripts that are written in one language,
    compared to Ninja, where it's meant to be generated from something
    else. Requiring just ghc and nothing else, is easier to sell,
    given how easy it has been dependency-wise (breakage, etc.) to
    install ghc on various Linux or BSD distros I've tried it on.

a3) As an extension of (a2), it's preferable to write build scripts in
    Haskell than Guile Scheme, and anything we can do to make that
    easier is a good thing. We don't want to move m4+(auto)make+sh to
    Scheme, where it's arguably easier to publish broken scripts due
    to the dynamic nature them.

Why do I think it's not a big deal to do it this way?

b1) Seeing how Shake is needed to build ghc itself, Edward's working
    on using it in ghc --make, and both cabal and stack devs are
    looking into reusing Shake, it makes a whole lot of sense to not
    make it an extra dependency.

b2) The way I see it, relying on Alex and Happy is, for instance,
    different, as those are usable as plain executable without a
    Haskell library. So, by keeping Shake bundled like xhtml or
    process, we'd not add external dependencies that need ghc and
    maybe cabal/stack to be built.

b3) Just like everyone is free to use a newer xhtml, regardless of
    what's bundled with a ghc release, nothing prevents you from
    installing a newer Shake than what's in the ghc release. Thus, I
    don't think we'd have to make it ghc-private.