Longstanding issues: structs & standalone Erlang

Mikael Karlsson mikael.karlsson@REDACTED
Wed Feb 22 23:34:20 CET 2006

onsdag 22 februari 2006 10:11 skrev Claes Wikstrom:
> Bengt Kleberg wrote:
> > i try to voice the opinion that configure, make, make install is not 
> > easy for everybody.
> > i could be wrong. 
> Yes,
> /klacke

I would not be that sure that this is wrong. 
It is easy if you have the tools installed, but that may not always be the 
case. And there is a point in having a pure Erlang system (like REPOS ?)
that can deploy "pure" erlang packages.
See the other thread:

Suppose 80 % of Erlang applications are not "contaminated" by C-code :-)
then it would be nice to have a way to deploy them on an installed Erlang
base system without having to think about other infrastructures. There 
should be some benefit of running on top of a VM. Java/Ant is another
example of this.

Why not make deployment apps like erlmerge sensitive about if there is a 
Makefile or an Emakefile (or none) and decide which route to take.

The problem with deployment on Erlang, as I see it, is that it is not possible
to add new applications to releases, and that they all have to go into the
erlang root library. It would be nice if Erlang could have a secondary
library path that was searched too, meaning that you could deploy applications
in an own library without having to do code:add_path{a,z} for everyone of 
them. And making it easy to upgrade your Erlang base system without affecting 
your own additions.


More information about the erlang-questions mailing list