[erlang-questions] Stand Alone Erlang or Equivalent

Peter K Chan peter@REDACTED
Wed Sep 5 19:36:30 CEST 2007

While not strictly necessary, there is still some advantage of having a
single, monolithic executable. For example, upgrading could be that much
easier, and so is deployment (just run the .exe).

Until the day of SAE is resurrected, I think the approach by Wings 3D
works well. I installed it a few weeks ago and I think it would be a
simple matter to reuse their packaging; just replacing the Wings 3D code
with your own code.

CEAN should work the same way too, I just haven't seen a standalone app
distributed with CEAN yet. I also considered CEAN as a deployment
packaging, but it seems to have a lot of files, especially on windows,
and I wasn't clear to me (with my limited understanding), which was
needed and which could be stripped out.


-----Original Message-----
From: erlang-questions-bounces@REDACTED
[mailto:erlang-questions-bounces@REDACTED] On Behalf Of Bob Ippolito
Sent: Wednesday, September 05, 2007 11:14 AM
To: Benjamin Tolputt
Cc: erlang-questions@REDACTED
Subject: Re: [erlang-questions] Stand Alone Erlang or Equivalent

On 9/5/07, Benjamin Tolputt <bjt@REDACTED> wrote:
> Bob Ippolito wrote:
> > Out of curiosity, what's the problem with a CEAN style solution?
> > a standalone environment that you can move anywhere on the
> > and it should still work. Other than the naming of the directories,
> > it's not much different than how Mac OS X applications are packaged,
> > and nobody really complains about that.
> >
> > -bob
> >
> The problem is that the CEAN distribution requires the user to extract
> files to a directory tree THEN run a separate executable. For servers
> and so on (which generally require some form of "setup" to install
> anyway) this is not an issue, but for game development (the area of
> development the guys are working in) this is not so good (impatient,
> technically inexperienced user base).
> Something along the lines of a Py2EXE would be ideal. Py2EXE zips and
> concatenates the required Python ".pyd" (i.e. Python's equivalent to
> "beam" files) to the end of an executable stub. This executable stub
> knows that it needs to retrieve the required code files (or in our
> Erlang "beam" files) from the compressed archive at the end of the
> rather than from the local file-system.

I don't buy it. I never see files distributed online as a single
".exe" file unless it's an installer. More often it's either as a zip
or a msi, either of which will carry multi-file payloads just fine.

erlang-questions mailing list

More information about the erlang-questions mailing list