search

paritytech / revive

Solidity compiler for PolkaVM
Apache License 2.0
38 stars 5 forks source link

Create `alpine` release of revive compiler (musl.libc) #45

Open smiasojed opened 2 months ago

smiasojed commented 2 months ago

Create the release workflow for revive compiler. As artefacts provide:

  1. revive-musl version
  2. alpine docker
  3. revive-glibc version
xermicus commented 2 months ago

The musl build should be beneficial for the remix backend.

athei commented 2 months ago

Glibc version should not be necessary. A statically linked revive-musl should have zero dependencies. Hence it will also run on glibc distros.

athei commented 2 months ago

@wpt967 Can you take care of this and then go back to the debugging work?

It will essentially mean creating github actions to produce the two artifacts (1 + 2).

ghost commented 2 months ago

Sure.

xermicus commented 2 months ago

@wpt967 thanks a lot!

I think how we should do it for now: The musl workflow should only run on pushes to the main branch and depend on the success of build-ubuntu-x86 (see here). This second workflow can then just build musl, build revive linked against musl, and finally build and publish an alpine Docker image containing the musl revive build.

Should probably also just add a Makefile target install-musl that produces a release build of revive linked against musl.

So, essentially each time we push something to main and the CI passes we'll get a fresh image, which should be good to iterate quickly. Later we can think how to do releases properly (we also want some matrix testing against solc versions etc., but thats for later).

smiasojed commented 2 months ago

In the Docker image, we need to include both 'resolc-musl' and 'solc-musl'. I would like to ask you to create the first revive release, which I can use as the base for the revive-remix-backend.

athei commented 2 months ago

I wouldn't add the musl suffix to resolc. We should not do any dynamically linked releases anyways as they wouldn't be portable. Or is there any reason to do so?

smiasojed commented 2 months ago

I just wanted to emphasize that we need both in the musl versions. We shouldn't have any suffix.

xermicus commented 1 month ago

https://gitlab.com/taricorp/llvm-sys.rs/-/issues/44

With this we can give it at shot again. Just need to make sure we pull in the latest version through inkwell. Probably our best bet is on using https://github.com/rust-cross/rust-musl-cross as cross-compilation ought to work even with proc-macros.

xermicus commented 1 month ago

Needs a llvm-sys release first. To try this out now:

athei commented 1 month ago

So there is an issue with llvm-system which is fixed on master but no release, yet?

xermicus commented 1 month ago

No, sorry I didn't realize it. They backported the fix to llvm-sys 181.2.0 which is published. So probably only a matter of bumping it in inkwell