[erlang-questions] Customizing Beam Build

[Sargun Dhillon]

I've customized my OTP build to have a custom Erlang build. The reason
I've done this to begin the process of building a fully-self contained
Erlang program. One of the biggest benefits of the infrastructure in
Go is that they're fully self-contained statically linked binaries. In
Erlang, although you can statically link beam itself, unfortunately,
the releases themselves are messy, in that you have a lot of files and
getting the execution environment right isn't always trivial.

Eventually, the purpose is to build an init system -- something that
will be primarily used by sysadmin-types. These need to be statically
linked, and often times, the file system isn't fully-functioning when
they're starting.

 I've done two things:

1) I've modified the set of preloaded files in the VM. It would be
really nice if there was a way to do this without forking OTP. I
didn't add any existing beam files, but I just changed around some of
the file, and code loading code to my need.

2) I've modified the final, linked product to include custom objects
in the final ELF binary.

This is kind of terrible, as it requires I maintain a fork of OTP.
Does anyone have any recommendations for solving this problem another
way?

My proposal would be to output a beam.a file with the requisite
objects to build a BEAM installation. It would be valuable if I could
statically link against this binary, and own main, if it had a
separate entrypoint that I could then call into. I've toyed around
with this, and for the unix build, it seems possible. Is there any
reason why Erlang isn't distributed this way already?

If there was a public API for extending the loader, or adding
preloaded modules via sections, I imagine that solving (1) would be
easy as well.

Is anyone open to accepting this upstream if the work is done?