Asterius toolchain declarations

[ylecornec]

Depends on #1618

This PR contains the declarations of the asterius toolchains.

Declarations alongside regular toolchains.

Asterius is not able to implement a full haskell toolchain by itself and needs to rely on a regular one (in particular we need runghc for cabal support).

In order to declare asterius and regular haskell toolchains together there is a new optional asterius_version attribute to haskell_register_ghc_nixpkgs and haskell_register_ghc_bindists: if it is present, we try to also declare asterius versions of the variours haskell toolchains.

At the moment only linux is supported.

The bundle.

For both nix and bindists, we download the same bundle made using the proverbial daml script.
This bundle contains asterius, Tweag's fork of wasi-sdk (the cc toolchain targetting WebAssembly) and the needed dynamic libraries.
It is temporariy uploded to this repository, the plan is to recover it later from the asterius repository once it can build in its ci.

Asterius toolchain type.

We declare a new toolchain type for asterius binaries that are not part of the regular haskell toolchain. It only contains the ahc-dist binary which generates .js files from a haskell "binary" built with the asterius based haskell toolchain.

[dpulls]

🎉 All dependencies have been resolved !

[aherrmann]

Great work!

A couple comments.

Asterius is not able to implement a full haskell toolchain by itself and needs to rely on a regular one (in particular we need runghc for cabal support).

Just to be sure I understand correctly. This is not something that the Asterius toolchain needs to track itself explicitly. Instead this is taken care of by the changes introduced in #1510. Correct?

[aherrmann]

Suggested change

	name = "asterius-toolchain",
	name = "toolchain_type",

The documented convention is to use the name toolchain_type for toolchain_type targets. (I know the Haskell toolchain doesn't follow it either, but that's only for historical reasons)
Is there a good reason not to follow this convention with this new toolchain?

[aherrmann]

Anything that doesn't start with _ is publically exposed. These look more like local helpers, correct? If so, better to prefix _ and not expose them.

[aherrmann]

I think we can follow the rule author guidelines here as well. This file should then be named repositories.bzl.

[aherrmann]

Is this one meant to be public? Otherwise, also prefix with _.

[aherrmann]

Perhaps rules_haskell_asterius_toolchains would be a better name for this. Following the pattern recommended here and also the naming here.

[aherrmann]

This is a regular rule, so probably better placed into haskell/asterius/defs.bzl. Then the ghc.BUILD.tpl also doesn't have to import asterius_workspace_rules.bzl (or repositories.bzl) which would be a strange import for a BUILD file.

[aherrmann]

If this is the user facing function, then all the attributes should be documented in the docstring here.

[aherrmann]

As I understand the following comment

For both nix and bindists, we download the same bundle made using the proverbial daml script.

the Asterius bindist is a self contained bundle. So, under which circumstances would the nix attribute need to be True?

[aherrmann]

Oh, I see. The asterius toolchain is attached to a Haskell toolchain (either bindist or nixpkgs) and the nix parameter is used to select the correct one out of those two.
Yes, that's a valid approach.

If I understand correctly the Asterius toolchain does not itself directly depend on the regular GHC toolchain. It only depends on it indirectly through the runghc attribute on the Cabal rules.

Would it be possible to define only one Asterius toolchain in the WORKSPACE by directly calling a user exposed rules_haskell_asterius_toolchains and leave it to Bazel's toolchain resolution to find the correct regular GHC toolchain for the Cabal rules? That would drop the need for the nix parameter and would seem a bit more modular.

What do you think?

[ylecornec]

Yes this would be better.
I was under the impression that this was not possible, because the asterius haskell toolchain would depend on another toolchain of the same type (but targeting another platform) so it looked a bit like a circular dependency.
But I just tried it and it seems to work 👍

[ylecornec]

Just to be sure I understand correctly. This is not something that the Asterius toolchain needs to track itself explicitly. Instead this is taken care of by the changes introduced in #1510. Correct?

Yes it seems so. I was not aware of this so I assumed the runghc from the toolchain was used.

So at the moment tools from the regular haskell toolchain are used to complete the asterius toolchain.
But in the end, ahc and ahc_pkg are the only tools of this toolchain that are actually executed.
(Since haddock is not supported, and I did not look into coverage or repl support yet).

For later, I think that hsc2hs should be useful once asterius supports C interop.
And I am also thinking about making the unlit binary explicit in the toolchain, to make it available to asterius for litterate haskell.

Readthedoc

The build fail looks quite similar to This issue. I will try to look into it.

About the diff

• I addressed the various comments.
• Renamed asterius/asterius_workspace_rules.bzl to asterius/repositories.bzl
• Renamed asterius/asterius_repositories to asterius_dependencies.bzl and reexported functions asterius_dependencies_nix and asterius_dependencies_bindist from asterius/repositories.bzl
• The documentation for asterius functions is not built with stardoc yet. Some of them depend on rules_nodejs so I encountered this issue and it seems hard to work around.
• The Nixpkgs platform constraints fix commit is there because the constraints are never actually None inside the repository rule (event if the rule is called with None the default value [] is then used). If we want to distinguish None and [] (to be able to explicitly set empty constraints sometime ?) then we need a different fix.

[aherrmann]

• The documentation for asterius functions is not built with stardoc yet. Some of them depend on rules_nodejs so I encountered this issue and it seems hard to work around.

Ah, yes, that looks tricky. Good call to skip for now.

• The Nixpkgs platform constraints fix commit is there because the constraints are never actually None inside the repository rule (event if the rule is called with None the default value [] is then used). If we want to distinguish None and [] (to be able to explicitly set empty constraints sometime ?) then we need a different fix.

Good catch!

[aherrmann]

Thank you! Great work!