Add a reusable GitHub Action that installs MicroHs

[sol]

This PR provides a GitHub Action to install a "nightly" build of MicroHs for CI use by third-party packages.

• This reduce e.g. the QuickCheck MicroHs CI time by -2 minutes.
• It also lowers the barrier to add MicroHs CI jobs to more projects.
• Right now this still uses binaries from my fork, this is why it is a draft PR for now. I have a separate PR in the pipeline to remedy this.

I also added instructions to the README on how to set up CI for a third-party package. I don't care about the exact wording so please feel free to change things as you see fit.

[augustss]

I like the idea, but I have some issues with the execution of it.
I think the bundle that should be produces nightly should be the files in generated/, src/runtime, together with base.pkg. Installing them is then a matter of compiling the three .c files, copying the runtime, and having mhs install the base package.

I've been planning to make a Makefile target that builds such a bundle for people who want to install MicroHs quickly.
But it's not done yet.

[sol]

OK let's make sure that I understand you correctly.

There are two steps:

• Creating MicroHs-linux-x86_64.tar.gz on each push to master (PR Publish MicroHs "nightly" binaries #337)
• Providing a GitHub Action that enables third parties to install MicroHs-linux-x86_64.tar.gz (this PR)

Are you saying that MicroHs-linux-x86_64.tar.gz should be created differently? (basically changing PR #337).

Or is there also something related to this PR that you think should be done differently?

[sol]

OK, so I think you are saying we should package C bootstrap sources and not produce any binaries at all, right?

How long does it take to compile the C sources + build the base libraries? Would that still give us any time savings on CI?

[sol]

I think the bundle that should be produces nightly should be the files in generated/, src/runtime, together with base.pkg.

OK from what I understand:

• generated/ contains the combinator graph for the three executables, scaffolded in a way so that a C compiler can compile it.
• I guessbase.pkg is what the README calls a "precompiled package". I assume this is also a combinator graph making up all of the base libraries, in binary form.
• src/runtime should just be ordinary C.

I assume all of these are platform independent. I agree that this is more suitable for distribution to a wider audience.

I'm not opposed to that approach. I still observe that if you only care about (linux) CI use, then it does not really make a difference.

If there is a significant speed difference between the two approaches, then I would argue that you could provide both, a fast non-portable way for CI use, and a slower but portable way for general consumption.

Installing them is then a matter of compiling the three .c files

Makes sense ✅

copying the runtime

I was about to say also compile, no?

But, yes, it makes sense, you only compile the runtime with the final executable ✅

(That makes me puzzle whether we compiled the runtime system three times, once for each executable in the previous step? Or do we share object files?)

and having mhs install the base package.

Here I'm a little bit lost. My naïve assumption would be that the base.pkg just needs to be copied, and only when we compile an executable we take the relevant parts from base.pkg and include them into the C scaffold.

What exactly does "having mhs install the base package" entail here? 🤷‍♂️

I've been planning to make a Makefile target that builds such a bundle for people who want to install MicroHs quickly. But it's not done yet.

The main effort here would be the install script, right? Or are there any other complications?