Use installed ghc in stack linux builds

[jneira]

• To avoid download it again and not waste disk space
• Fixes Azure stack linux jobs fail due to disk space #1729
• The builds are failing due to timeouts when executing stack exec hoogle generate: see Timeouts downloading cabal.config's from stackage in azure ci ndmitchell/hoogle#347

[fendor]

LGTM!

[jneira]

I am afraid that the actual configuration is not valid for wrapper-test, cause it assumes that stack will have the correct ghc downloaded or in path. It needs up to two different ghcs (ghc-8.8.1 and ghc-8.6.5) so not sure if it will be enough space for both although we are not downloading the main one, the used to build everything else.

[fendor]

How about we mock the wrapper tests? You think that is possible?

[fendor]

Idea for test-mocking:

• Add a number of scripts named ghc-* where * is the GHC version
  • These scripts can be python scripts, or if it works, there can be both ghc-* and ghc-*.cmd
• Each of these scripts only know the parameter --numeric-version
• When running wrapper tests, we do something like export PATH=/path/to/scripts:$PATH
• For stack, set system-ghc: True.

[jneira]

Mmm, interesting, but stack with system-ghc needs an executable ghc (without the version suffix) in path, no? (i have to test it) could we cheat stack and make it think that the script is ghc?

In fact, we have the real ghcs! so we could point to the appropiate one for each test. This can be done manually running each test separately and set the path with the appropiate ghc in the bash script.
EDIT: No it cant be done in that way cause the execution itself needs the main ghc

Not pretty, though 🤔

[jneira]

but stack with system-ghc needs an executable ghc (without the version suffix) in path, no? (i have to test it)

I was wrong, stack picks a ghc-${version} in path if it needs it so the solution is simpler than i thought: we can set in path the needed ghcs, putting the main one in first place

[jneira]

Ok, the stack linux jobs that has not failed due to the response timeout are successful now, so i think the pr could be merged