When using compiled escripts to share Erlang programs the program author and the program user need to have compatible versions of Erlang and the BEAM installed. If one was using OTP26 and one was using OTP29 the escript would likely fail to run and show a cryptic error message, confusing the user.
I’ve been trying to work out a way to have the escript start by checking the running VM version, printing a helpful message if it is likely not compatible, as I think this would greatly help with the user-experience of escript programs.
My thought was that perhaps the escript zip archive could contain a single not-yet-compiled Erlang source module, and have that do the checking before running the already-compiled code, but I’ve not discovered a way to do that from reading the source of escript.erl.
Is there a way to embed forward-and-backwards compatible code within a compiled escript?
Alternatively, is there some other way to improve the error message? To make it more understandable to users without this Erlang knowledge.
Aye! Getting metadata into the script is easy, but I was unable to work out how I could use said metadata as the precompiled .beam files may not be executable. How would you use that metadata?
Would it be possible to mix compiler versions within the escript? My first thought is to have a stub that’s compiled with a minimum version (OTP-26) that runs whatever checks you need before calling the real entry point that’s compiled with OTP-29.
I might be mistaken, but I don’t believe the bytecode is not forwards compatible, so older versions may not work. That or my older escripts failed for some other reason!
My thought was to update the escript executable to check this metadata. Sounds like you’re after something you as the builder of an escript could do w/o modifying escript. Off the top of my head you would either need to not compile the modules, or wrap it in a shell script that does the version check before either running the escript or printing the user-friendly message you’re after.
As long as the BEAM doesn’t guarantee that I’ll run arbitrarily old .beam files, there is not going to be any form of “universal” BEAM object files or executables (compiled escripts).