[erlang-questions] Customizing Beam Build

[Tristan Sloughter]

I like the idea of easily built static builds but for dealing with
releases being messy (if I'm understanding what you mean) is something
that may be solved simply with existing tools like makeself:

http://makeself.io/

-- 
  Tristan Sloughter
  "I am not a crackpot" - Abe Simpson
  t@REDACTED

On Sun, Sep 24, 2017, at 01:25 AM, Sargun Dhillon wrote:
> 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?
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions