Adding GHCup targets for build, update, serve

[Aster89]

I'm not using Nix, but GHCup, and I had to adapt the Makefile a bit to make this project work.

These are the 2 targets I've used (ghcup-build/ghcup-serve corresponding to build/serve), plus another one (ghcup-update corresponding to update) which seemed easy to adapt.

[dmjio]

This looks good, but can we also update the github CI workflow action to include the ghcup github action - should install it automatically in CI.

Can we also install and select the cross compilers we need (JS / WASM), and then make sections in the workflow file.

- name: Build JS using GHCUp
  run: -- command goes here
  
- name: Build WASM using GHCUp
  run: -- command goes here

[Aster89]

I suppose this should have a better name?

Should it be Build WASM using GHCup in alignment with the existing Build WASM using Nix?

[Aster89]

I meant to comment line 41 only :|

[hasufell]

I fixed the issues here: #15

[Aster89]

Thanks @hasufell for fixing this in #15.

[Aster89]

Reopening to submit on behalf of @hasufell.

Regarding Julian's change, I'm copying here a piece of our conversation for my own memory as regards the reasons for the changes:

Me:

Other than the cosmetic/readability changes (e.g. using variables in the Makefile), I seem to understand that these are the actual changes you've made to fix my broken pr:

1. not passing any version to the various --with-* cabal flags
   • is this fundamental to the fix?
2. sourcing ~/.ghc-wasm/env before cabal build
   • why is this necessary, given that install-wasm-via-ghcup runs before cabal build anyway?
3. joining some commands via &&
   • is this just to, say, avoid running ghcup config add-release-channel $(RELEASE_CHANNEL) if . ~/.ghc-wasm/env fails before it, i.e. just to save time in case of failure?
4. changing $CONFIGURE_ARGS to $$CONFIGURE_ARGS
   • I suppose this is my gross mistake of not remembering the distinction between make-specific and shell-specific variables. Is by any means this the fundamental mistake I made?
5. changing ghcup install ghc wasm32-wasi-9.14 to ghcup install ghc --set wasm32-wasi-9.15
   • is --set necessary?
   • I suppose the change in version is just incidental?

@hasufell:

1. no, it just makes it easier to update the GHC version
2. yes, I think this is the main issue... you're executing the sourcing and the build in separate steps... every step in a github job is a separate script, so the sourcing of the previous step has no effect
3. in the Makefile, every line in a rule is a separate command as well, similar to point 2... if you want the subsequent commands to see the sourced environment, you have to combine them like that
4. $CONFIGURE will expand to the Makefile variable, not the enviromnent variable... so double $$ escapes it for shell variables
5. --set just makes it so that we can later say cabal build -w wasm32-wasi-ghc without the version, it simplifies the makefile

[dmjio]

Looks good, should we also add a JS backend build w/ GHCUp as well? Or can do that in a follow up PR.

[dmjio]

why have . ~/.ghc-wasm/env here?

[dmjio]

#19