Compiling a release for another architecture using ERTS

I’d like to describe the way we’re compiling our release and see if there are any known problems with this approach.

As we all know, when compiling a release, it’s important to use the Erlang Runtime System for the target operating system.

As a team we have various OS’s so obviously we can’t just mix release. Instead we have a script which uses the latest Erlang docker file, and copies the ERTS folders onto the host. This only needs to happen once (unless you delete the files).

After that, we are now free to build our release using mix, with a target that specifies include_erts: "../path/to/erts".

With this approach, we can compile releases super quick as we’re only compiling our own app code.

The only downside we have found so far is that we’re forced to use Debian because that’s what the official erlang:latest docker file is based on. I’m sure you could create your own with your desired OS if required of course.

I’m interested if anyone else is doing it this way?
And if so, are there any downsides, or gotcha’s that we might bump our head on?

Just build in the container, thats probably easier… Also thats adoptable to your CI chain as well.

Next is, ERTS is not the only thing to consider, but also NIFs, as soon as you start to use NIFs, more things get important…

Also there are other images available, eg. @beardedeagle s builder images which run on alpine. And to be honest… It should be trivial to create an RedHat or CentOS or even Arch container that you can use to build your pipeline on (or extract ERTS from).

1 Like

Thanks for the rather direct advice! Good shout on the NIF’s tho I hadn’t considered that. Also hadn’t heard of @beardedeagle 's builder images, so thanks I’ll check them out.