Re: Why the difference between lang/elixir and lang/elixir-devel? (also: elixir-devel doesn't support mix release)

On Tue, 10 May 2022, at 04:12, Pat Maddox wrote:
> I had been working on a patch to lang/elixir-devel to support mix 
> releases, per the problem I shared in 
> https://lists.freebsd.org/archives/freebsd-erlang/2022-May/000629.html
>
> When working on it, I saw that lang/elixir doesn’t have the problem - 
> it doesn’t patch `elixir` to “hard-wire” the OTP release. So I can 
> just depend on lang/elixir instead.
>
> I had assumed that lang/elixir-devel just provided a more up-to-date 
> version of elixir, to get access to a newer elixir while still using 
> quarterly ports.
>
> That appears not to be the case. Two key differences I note are:
>
> 1. lang/elixir depends on lang/erlang, whereas lang/elixir-devel depends 
> on lang/erlang-runtime*
> 2. lang/elixir builds elixir as-is, whereas lang/elixir-devel patches 
> the `elixir` script to “hard-wire” the OTP release.
>
> What is the intent of the lang/elixir-devel port?

Hi Pat

TLDR log an issue against lang/elixir-devel for fixing mix release &
tracking this. The OTP21-OTP22 transition was a major breakage point
for OTP stdlib and stuff needed to be hard wired to work reliably.

-devel flavoured ports are the leading edge of ports dev. As a ports
committer it allows me to easily switch a subsidiary port (like
net/rabbitmq or phoenix) over for testing, as I choose, & back again.
As a user, it allows me to test my apps against the very latest.

A little bit of history. In FreeBSD ports, we have had since time
immemorial:

lang/erlang: the main stable OTP release, which the ports variants (-java
-wx -man -doc) are built off, and corresponding tools like rebar & elixir
are built from.

lang/erlang-runtime${...}: same build system, newer & older OTP releases,
to accommodate dependencies that were ahead or behind of the curve.

The bytecode produced by different erlang versions isn't fully compatible
between versions. We needed, at least in previous releaess, to ensure that
newer elixir is always built (and therefore used) against newer bytecodes.
This was particularly relevant when erlang native-compiler and hipe was
still common.

For quite a while we had elixir versions that could only be built off the
newer OTP releases, thus erlang-runtime${...} dependent, and thus the
build hooks, your #2.

Last year, we cleaned up and deprecated ports that were not buildable on
recent supported OTP releases.  This was really only moving along once
the OTP team declared their official support policy, prior to that we just
kept everything back to ~R15~.

Last year, OTP24 was released, with JIT support, and this felt new enough
to not switch things over to it by default, and yet ideal for an
elixir-devel port to link & test against. At that time, lang/erlang was
still OTP21, and a very large number of erlang & elixir modules would
work on OTP21 and break on OTP22+ due to significant changes & deprecations
in OTP stdlib (logger, hipe, NIF API, crypto, erl_interface, ...) so we
needed to keep these things separate.

This year, when OTP25 is released, OTP21 will no longer supported, and
any dependent library that hasn't upgraded their supported OTP releases
can be removed from ports tree too, as clearly they're not keeping up. 

We can switch lang/elixir-devel to use any OTP release, as the lang/elixir
port now does.

A+
Dave