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.