<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi list,</div><div><br></div><div>I working to have one erlang wrapper similar how freewrap[1] is working for TCL.</div><div>Ideea is simple to bundle all in one exec file (Erlang VM, beam files, boot script)</div><div><br></div><div>Example usage can be:<br></div><div>erl_wrap.exe -out my_app.exe -wrap my_erlang_app<br></div><div><br></div><div>That works simple:</div><div>1) copy 
erl_wrap.exe to 
my_app.exe <br></div><div>2) append all Erlang app (beam files, boot script, ...) to 
my_app.exe file as resources.</div><div>3) And job done. Simple click to 
my_app.exe (On windows) or in console<br></div><div><br></div><div>
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">It is still at an early stage</span></span>, but I have results and 
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">I want to continue</span></span>. <br></div><div>
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">I know the 
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">work is </span></span>dirty now </span></span>but in final I want to be 
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">crazy simple</span></span>.

</div><div><br></div><div>Now I looking for advice how to integrate this 
erl_wrap library in one current ERLANG dev environment.</div><div>To do this hack I changed erlang/otp repo but I want to be able to build <br></div><div>
erl_wrap.exe only based


ERLANG dev environment based on compiled lib files and .h files.</div><div>What is need is a way to link erts (Erlang Runtime) and to alter preload beam files add wrap NIF files and output to 
erl_wrap.exe (all staticaly linked)<br></div><div>In this way erl_wrap can be independently and can integrated by anyone want to use.</div><div>Now I ask for advice to have this erls.lib (beam only) and separate lib for 
preload beam files. It this viable method? Do erlang team accept this work patch?<br></div><div><br></div><div>Second advice is what I can miss in this design, problems are many (ports from priv diretory, hot updates) but for my usecase to have one file is big win.<br></div><div><br></div><div>Now if this erl_wrap is call erl (erl.exe) and is someware in path all Elixir stuf is working (mix, iex, elixir), released not, but looks good.<br></div><div><br></div><div>Also 
EMU,ROOTDIR,BINDIR,PROGNAME do not have any utility now,</div><div>and are very used inside code.<br></div><div>On Unix we have erl script that set env vars and 
<span id="gmail-result_box" class="gmail-short_text" lang="en"><span class="gmail-">launch</span></span> erlexec that parse <br></div><div>all arguments and exec beam VM (Erlang VM), final process is beam.smp<br></div><div>On Windows we have erl.exe that read erl.ini and use erlexec.dll to parse arguments and start 
Erlang VM from beam.smp.dll, final process is erl.exe<br></div><div>In our wrap example final process is 
my_app.exe (my_app on unix) <br></div><div>and because all arguments are bundle startup is simple but env vars</div><div>EMU,ROOTDIR,BINDIR,PROGNAME do not have a meaning<br><br></div><div>If I have good results I will share as open source library.<br></div><div><br></div><div>[1] 
<a href="http://freewrap.sourceforge.net/">http://freewrap.sourceforge.net/</a>

<br></div><div><br></div><div>Thanks!<br></div><div>-- <br><div dir="ltr" class="gmail_signature">Petrica Clement Chiriac <br><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>