Remove Makefile & build-all.ps1 and leave only Shakefile

[Anrock]

Hey, three build scripts are too much.

Right now I'm making a PR that removes both Makefile and build-all.ps1 and updates README about that (also some DRY cleanups).

Is there any objections or specific blockers to using Shake script as the only build script?

Todo:

• Add 8.4.2 and 8.2.1 versions to hieVersions list in Shakefile Add 8.4.2 and 8.2.1 HIE versions to Shakefile #1034
• Remove v1 prefix from cabal commands (Remove v1 prefix from cabal commands in Shakefile #1043)
• Rename Shakefile to install.hs and update README (Rename Shakefile.hs to install.hs #1044)
• Remove mentions of Make/build-all.ps1 from README (Remove make section from readme #1120)
• Actually remove Makefile and build-all.ps1 scripts. (Remove non shake scripts #1140)
• Make sure that Shakefile implements everything as Makefile does (Recursively sync and update submodules in Makefile #1032, ???)
• Add some CI tests (separate PR by @bubba)

[Anrock]

@alanz @bubba @fendor

[fendor]

Following Blockers: Shakefile has the issue that not all supported ghc's are being installed. The list of ghc's is not complete.
Thus, the help message is actually wrong.

[Anrock]

@fendor it's seems 8.4.2 and 8.2.1 are the only ones that's missing. Would it be enough to just add them to hieVersions list?

[fendor]

yes that is enough

[lukel97]

Can you check that #1032 is also covered in the Shakefile?

[fendor]

We should also integrate #1008 into the install.hs, e.g. special handling of hie-8.6.3 on windows.

[Anrock]

@fendor afaik it isn't handled right now, so it's a separate issue.

[leifmetcalf]

What's the advantage of using shake over a normal haskell script?

[lukel97]

@leifmetcalf being able to define it in terms of targets and build rules means it can work out the dependency graph for each binary and only build what’s needed. And it also provides the command line interface for free

[leifmetcalf]

@bubba The current install.hs is just a bunch of phony rules, though.

[lukel97]

@leifmetcalf that is pretty confusing. I had to take a look at it again, but I think its because the path to the hie-x binaries are buried somewhere inside .stack-work, so the targets can't rely on Shake for detecting if its dirty or not since we don't know the path. But thankfully stack already takes care of not doing redundant rebuilding. The phony rules still provide dependencies though between the different levels of installation that can occur (e.g. build hie for one version or for all versions)

[Anrock]

@bubba i think this is ready to land as soon as CI tests for install.hs are implemented.

[lukel97]

@Anrock just an update to let you know I'm still working on it! Ran into a bunch of issues with caching, I want to make sure that the shake file CI reuses as much cache as possible to prevent jobs from being bogged down

[Anrock]

@bubba how things going? Numerous issues regarding make-shake consistency appeared recently.

[lukel97]

@Anrock sorry for the delay: I hit a couple of walls when trying to merge multiple stack caches on CircleCI. For now I think this PR is fine to merge, and we can create an issue for the CI/testing

[Anrock]

@bubba ok, thanks. I'll try find some time to recheck what else isn't ported to install.hs and send a PR for review.

[Anrock]

I consider this as done.
Some work remains to do with CI (tests, maybe some cleanup), but i have no idea how to do it, so leaving it to @bubba