[UPDATE] lang/erlang

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[UPDATE] lang/erlang

niamkik
Hi,

I ported many different version of Erlang in the ports tree, based on the past modification I already made. Here the supported version:

- 21.3.8.22
- 22.3.4.17
- 23.3.1
- 24.0-rc2 (should not be released, was just created to test the last release)

I can build, package and install them locally. I did not tested them more deeply right now and I am waiting for feedback. Only missing version is the last R19 but should be easy to port. For the one interested, these patches were created and available here: [https://github.com/niamtokik/ports/tree/erlang/lang/erlang](https://github.com/niamtokik/ports/tree/erlang/lang/erlang/21).

erlang.tar.gz (157K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [UPDATE] lang/erlang

Greg Steuck-5
Hello,

Thanks for doing all this work. We can probably deal with this after the
tree unlocks.

niamkik <[hidden email]> writes:

> Hi,
>
> I ported many different version of Erlang in the ports tree, based on the past modification I already made. Here the supported version:
>
> - 21.3.8.22
> - 22.3.4.17
> - 23.3.1
> - 24.0-rc2 (should not be released, was just created to test the last release)

Since I pruned the old erlang versions in ports, I've got to ask. Would
we get sufficient benefits from keeping more than one erlang version? Do
we have important erlang software people rely on that we can't build
with a single chosen version?

We routinely make decisions choosing single library versions. It makes
sense to lean this way for the compilers...

Thanks
Greg

Reply | Threaded
Open this post in threaded view
|

Re: [UPDATE] lang/erlang

niamkik
Hi,


> Since I pruned the old erlang versions in ports, I've got to ask. Would
> we get sufficient benefits from keeping more than one erlang version? Do
> we have important erlang software people rely on that we can't build
> with a single chosen version?
>
> We routinely make decisions choosing single library versions. It makes
> sense to lean this way for the compilers...

On my side, maintaining 4 versions will not be easy but I can understand to have backward compatibility with older version, it could be nice. Anyway, maintaining only one release could be easier, like R22 or R23. It will probably lead to break dependencies though.


Reply | Threaded
Open this post in threaded view
|

Re: [UPDATE] lang/erlang

Stuart Henderson
On 2021/04/09 07:19, niamkik wrote:

> Hi,
>
>
> > Since I pruned the old erlang versions in ports, I've got to ask. Would
> > we get sufficient benefits from keeping more than one erlang version? Do
> > we have important erlang software people rely on that we can't build
> > with a single chosen version?
> >
> > We routinely make decisions choosing single library versions. It makes
> > sense to lean this way for the compilers...

Libraries are often difficult to handle with multiple versions, they often
conflict and cause problems if several are installed together. Though in
some cases it's fine, e.g. we often have multiple versions of gtk+,
gegl, gstreamer in parallel, but it does require some thought.

For interpreters there's often good reason to have multiple versions
(see php, python, lua, ruby) and *if* there's a good reason and
somebody is willing to maintain then I wouldn't object to that.
(That latter point is key though, if it's not going to be actively
maintained then it really wants keeping simple).

> On my side, maintaining 4 versions will not be easy but I can understand to have backward compatibility with older version, it could be nice. Anyway, maintaining only one release could be easier, like R22 or R23. It will probably lead to break dependencies though.

Most of the dependencies are either already broken (riak, rabbitmq),
or can handle at least up to 23 (rebar3, elixir). The others are rebar
(no longer maintained and only used in ports as a dependency of riak)
and tsung (no indication whether it will work or not and doesn't exactly
seem active upstream).

(riak is a bit special anyway, seems they really want it to be built with
a patched Erlang..)

Reply | Threaded
Open this post in threaded view
|

Re: [UPDATE] lang/erlang

niamkik
> For interpreters there's often good reason to have multiple versions
> (see php, python, lua, ruby) and if there's a good reason and
> somebody is willing to maintain then I wouldn't object to that.
> (That latter point is key though, if it's not going to be actively
> maintained then it really wants keeping simple).

It's quite okay for me. I am documenting the process right know to maintain each individual version of Erlang for OpenBSD. It should be easier for me in few days/weeks.

> Most of the dependencies are either already broken (riak, rabbitmq),
> or can handle at least up to 23 (rebar3, elixir). The others are rebar
> (no longer maintained and only used in ports as a dependency of riak)
> and tsung (no indication whether it will work or not and doesn't exactly
> seem active upstream).
>
> (riak is a bit special anyway, seems they really want it to be built with
> a patched Erlang..)

I started to rework on these ports with previous ported version. I have this list:

 - benchmarks/tsung
 - databases/riak
 - devel/rebar
 - devel/rebar3
 - lang/elixir
 - net/rabbitmq

The goal is to also add other Erlang application directly in the ports like VerneMQ or Wings3D for example.

Reply | Threaded
Open this post in threaded view
|

Re: [UPDATE] lang/erlang

Greg Steuck-5
niamkik <[hidden email]> writes:

>> For interpreters there's often good reason to have multiple versions
>> (see php, python, lua, ruby) and if there's a good reason and
>> somebody is willing to maintain then I wouldn't object to that.
>> (That latter point is key though, if it's not going to be actively
>> maintained then it really wants keeping simple).
>
> It's quite okay for me. I am documenting the process right know to maintain each individual version of Erlang for OpenBSD. It should be easier for me in few days/weeks.

I would still strive for the minimal number of erlang version to keep.
If all the dependent ports software can be built with a single (most
supported?) version we'll come out ahead with less stuff.

>> Most of the dependencies are either already broken (riak, rabbitmq),
>> or can handle at least up to 23 (rebar3, elixir). The others are rebar
>> (no longer maintained and only used in ports as a dependency of riak)
>> and tsung (no indication whether it will work or not and doesn't exactly
>> seem active upstream).
>>
>> (riak is a bit special anyway, seems they really want it to be built with
>> a patched Erlang..)
>
> I started to rework on these ports with previous ported version. I have this list:
>
>  - benchmarks/tsung
>  - databases/riak
>  - devel/rebar
>  - devel/rebar3
>  - lang/elixir
>  - net/rabbitmq
>
> The goal is to also add other Erlang application directly in the ports like VerneMQ or Wings3D for example.

Let the application requirements guide the set of compilers to support.

Thanks
Greg