amesgen
commented
10 months ago This repo was originally intended just to provide stable/non-vanishing bindist links for ghc-wasm-meta, but I think it should also be fine for other projects to use them. Note that this is relying on the generous policy by GitHub to accept lots of releases with large attached files.
Currently, it is not documented how to consume this repo, so here are some thoughts on your use case:
- To get the latest bindist that is mirrored here for the
ghc-9.6/ghc-9.8branch in GHC, consult themeta.jsonfile: https://github.com/amesgen/ghc-wasm-bindists/blob/2c74790fda4ff109e158d887eae4222659e518c7/meta.json#L32-L41 Ignore the GH releases, they are just an implementation detail (they contain whatever bindists were new when the mirror job ran; so it can be the case that there was no new commit in eg the 9.8 release branch with a WASM bindist (in contrast to 9.6) that could be mirrored which explains the behavior you describe above). - The other bindists (which don't indicate any version) are
masterbindists, so they are probably not interesting for ghcup. Probably could add an indicative suffix :thinking:
HTH!
hasufell
The bindist in the releases are consumed by ghcup: https://github.com/haskell/ghcup-metadata/blob/25f6f8cfad751224be0a2a30f7d5f9be7e2c0cfb/ghcup-cross-0.0.8.yaml#L43-L55
It seems 20231001T201511 had a wasm32-wasi-ghc-9.8.tar.xz bindist, but the latest 20231224T201610 only has wasm32-wasi-ghc-9.6.tar.xz and a couple bindists that don't even indicate the ghc version.
This makes it hard/confusing what I'm dealing with. I don't want to unpack and inspect the bindists in order to add them to the ghcup metadata.
Can you make the bindist names uniquely descriptive? Why are the new ones 9.6?