MS Windows build use of versions in directory names/paths
Wed Mar 30 00:12:10 CEST 2005
Frank Seesink wrote:
> I'm relatively new to Erlang, so please excuse me if this has been
> covered. I've searched the FAQs and not found a reasoning, so thought I
> would post here.
> What exactly is the reasoning behind using version numbers in the
> directory names/paths in the Windows prebuilt binaries? That is, the
> latest version of Erlang as I write this is Erlang/OTP R10B-4 (release
> 23 Mar 2005). Performing a vanilla/standard install, the user has
> Erland installed in
> x:\Program Files\erl5.4.5
> and there is a subdirectory
> x:\Program Files\erl5.4.5\erts-5.4.5
I can see how this can be annoying for some uses but I would still
not like any major change to the current situation. We typically
have to support several versions of our application and these in
turn (often) use different versions of Erlang. This means that I
need to have several versions of Erlang installed in parallell on
my development environment.
With the current system this is a breeze. I simply install the
versions of Erlang I need. I can then work using any of the
installed versions without risk of using a newer compiler than I
want, or an older stdlib, or ...
The reason this works so well is because the versions install in
completely different structures. Not in spite of it.
> This issue came up for me as my introduction to Erlang came from looking
> into ejabberd, the Erlang-based Jabber/XMPP server
> (http://ejabberd.jabber.ru). Installing/running ejabberd requires
> Erlang, of course. And the ejabberd installer offers to create a
> Windows service so that a user can run ejabberd on system startup.
> However, the installation of this NT service involves launching Erlang
> and having it fire up ejabberd. This, of course, necessitates putting
> the PATH to the current installed version of Erlang into the appropriate
> place in the Windows Registry
> (HKLM\SYSTEM\CurrentControlSet\Services\ejabberd...) where the NT
> service is set. (Note this is not something many users will understand.)
I don't know how ejarrerd works and this is not an argument either
for it or against it. Our application, which is run in a Windows
environment, is built to work with a specific version of Erlang.
Each version is verified for one Erlang version only. Running it
using a different version of Erlang is NOT supported.
To make this work our installer checks for the required version
of Erlang. If that version is not found it will be installed.
Once the correct version of Erlang is available that version is
used by the installer to run the erlsrv application to install
or update the Windows services. The services will then be
registered with a full path to the required Erlang version.
Selecting the version of Erlang is (in our case) up to us. Not our
users. (They usually have no idea what Erlang is.) If they do
install another application using a different version of Erlang
that is not a problem. Our stuff still works just fine.
More information about the erlang-questions