[Buildroot] [PATCH] package/erlang: do not hard-code the Erlang Interface Version (EI_VSN)

[Buildroot] [PATCH] package/erlang: do not hard-code the Erlang Interface Version (EI_VSN)

[Yann E. MORIN]

The note above the erlang version instructs to refer to another note
further down the file. However, even if it is not too difficult to find,
it is still located a bit too far away, and the reference is not very
explicit what note we should look at.

When we introduced that variable in 6c1d128844c5 (package/erlang: export
EI_VSN so other packages can use it), the rationale for hard-coding it
was "to avoid spawning a shell every time the variable is dereferenced".

However, that can get a bit confusing and hard to follow. Also, that in
fact spawns a shell only once for each rebar-packages, so the overhead
is far from being too high.

The EI_VSN is only used by rebar-package packages, is derefrenced from
the rebar-infra and not the packages themselves, and is not needed by
erlang itself (it knows its own EI_VSN), so we can de-hard-code it, and
rely on build-time detection, by looking in the appropriate file.

We have two files where we could look:
  - lib/erl_interface/vsn.mk in the erlang source tree, but it is not
    installed,
  - .../lib/erlang/releases/$(ERLANG_RELASE)/installed_application_versions
    as installed by erlang.

We use the second one, as it is cleaner, for a package, to look into
installed files, rather than to look in the source tree of another
package.

Although both the host and target erlang are the same, we still look
into the corresponding file to extract the version. This is so that it
would be easier if in the future we ever manage to rely on a
system-installed erlang that could have a EI_VSN different from the
target one.

We can't re-use the variable ERLANG_EI_VSN, because it now needs to be
$(call)-ed with a parameter. Hopefully, external packages that use it
directly rather than through the rebar infra, are not legion...

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Will Newton <will.newton@gmail.com>
Cc: Johan Oudinet <johan.oudinet@gmail.com>
---
 package/erlang/erlang.mk | 8 ++++----
 package/pkg-rebar.mk     | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/package/erlang/erlang.mk b/package/erlang/erlang.mk
index ac2c204a49..5d6b69057a 100644
--- a/package/erlang/erlang.mk
+++ b/package/erlang/erlang.mk
@@ -4,8 +4,8 @@
 #
 ################################################################################
 
-# See note below when updating Erlang
 ERLANG_VERSION = 22.3.4.22
+ERLANG_RELEASE = $(firstword $(subst ., ,$(ERLANG_VERSION)))
 ERLANG_SITE = \
 	https://github.com/erlang/otp/releases/download/OTP-$(ERLANG_VERSION)
 ERLANG_SOURCE = otp_src_$(ERLANG_VERSION).tar.gz
@@ -36,9 +36,9 @@ ERLANG_PRE_CONFIGURE_HOOKS += ERLANG_RUN_AUTOCONF
 HOST_ERLANG_DEPENDENCIES += host-autoconf
 HOST_ERLANG_PRE_CONFIGURE_HOOKS += ERLANG_RUN_AUTOCONF
 
-# Whenever updating Erlang, this value should be updated as well, to the
-# value of EI_VSN in the file lib/erl_interface/vsn.mk
-ERLANG_EI_VSN = 3.13.2.2
+# Return the EIV (Erlang Interface Version, EI_VSN)
+# $(1): base directory, i.e. either $(HOST_DIR) or $(STAGING_DIR)/usr
+erlang_ei_vsn = `sed -r -e '/^erl_interface-(.+)/!d; s//\1/' $(1)/lib/erlang/releases/$(ERLANG_RELEASE)/installed_application_versions`
 
 # The configure checks for these functions fail incorrectly
 ERLANG_CONF_ENV = ac_cv_func_isnan=yes ac_cv_func_isinf=yes
diff --git a/package/pkg-rebar.mk b/package/pkg-rebar.mk
index e4e3f3bb6c..4b993dd970 100644
--- a/package/pkg-rebar.mk
+++ b/package/pkg-rebar.mk
@@ -32,10 +32,10 @@ REBAR_TARGET_DEPS_DIR = $(STAGING_DIR)/usr/share/rebar/deps
 #
 REBAR_HOST_DEPS_ENV = \
 	ERL_COMPILER_OPTIONS='{i, "$(REBAR_HOST_DEPS_DIR)"}' \
-	ERL_EI_LIBDIR=$(HOST_DIR)/lib/erlang/lib/erl_interface-$(ERLANG_EI_VSN)/lib
+	ERL_EI_LIBDIR=$(HOST_DIR)/lib/erlang/lib/erl_interface-$(call erlang_ei_vsn,$(HOST_DIR))/lib
 REBAR_TARGET_DEPS_ENV = \
 	ERL_COMPILER_OPTIONS='{i, "$(REBAR_TARGET_DEPS_DIR)"}' \
-	ERL_EI_LIBDIR=$(STAGING_DIR)/usr/lib/erlang/lib/erl_interface-$(ERLANG_EI_VSN)/lib
+	ERL_EI_LIBDIR=$(STAGING_DIR)/usr/lib/erlang/lib/erl_interface-$(call erlang_ei_vsn,$(STAGING_DIR)/usr)/lib
 
 ################################################################################
 # Helper functions
-- 
2.25.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/erlang: do not hard-code the Erlang Interface Version (EI_VSN)

[Arnout Vandecappelle]

On 10/02/2023 22:55, Yann E. MORIN wrote:
> The note above the erlang version instructs to refer to another note
> further down the file. However, even if it is not too difficult to find,
> it is still located a bit too far away, and the reference is not very
> explicit what note we should look at.
> 
> When we introduced that variable in 6c1d128844c5 (package/erlang: export
> EI_VSN so other packages can use it), the rationale for hard-coding it
> was "to avoid spawning a shell every time the variable is dereferenced".
> 
> However, that can get a bit confusing and hard to follow. Also, that in
> fact spawns a shell only once for each rebar-packages, so the overhead
> is far from being too high.
> 
> The EI_VSN is only used by rebar-package packages, is derefrenced from
> the rebar-infra and not the packages themselves, and is not needed by
> erlang itself (it knows its own EI_VSN), so we can de-hard-code it, and
> rely on build-time detection, by looking in the appropriate file.
> 
> We have two files where we could look:
>    - lib/erl_interface/vsn.mk in the erlang source tree, but it is not
>      installed,
>    - .../lib/erlang/releases/$(ERLANG_RELASE)/installed_application_versions
>      as installed by erlang.
> 
> We use the second one, as it is cleaner, for a package, to look into
> installed files, rather than to look in the source tree of another
> package.
> 
> Although both the host and target erlang are the same, we still look
> into the corresponding file to extract the version. This is so that it
> would be easier if in the future we ever manage to rely on a
> system-installed erlang that could have a EI_VSN different from the
> target one.
> 
> We can't re-use the variable ERLANG_EI_VSN, because it now needs to be
> $(call)-ed with a parameter. Hopefully, external packages that use it
> directly rather than through the rebar infra, are not legion...
> 
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Will Newton <will.newton@gmail.com>
> Cc: Johan Oudinet <johan.oudinet@gmail.com>
> ---
>   package/erlang/erlang.mk | 8 ++++----
>   package/pkg-rebar.mk     | 4 ++--
>   2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/package/erlang/erlang.mk b/package/erlang/erlang.mk
> index ac2c204a49..5d6b69057a 100644
> --- a/package/erlang/erlang.mk
> +++ b/package/erlang/erlang.mk
> @@ -4,8 +4,8 @@
>   #
>   ################################################################################
>   
> -# See note below when updating Erlang
>   ERLANG_VERSION = 22.3.4.22
> +ERLANG_RELEASE = $(firstword $(subst ., ,$(ERLANG_VERSION)))
>   ERLANG_SITE = \
>   	https://github.com/erlang/otp/releases/download/OTP-$(ERLANG_VERSION)
>   ERLANG_SOURCE = otp_src_$(ERLANG_VERSION).tar.gz
> @@ -36,9 +36,9 @@ ERLANG_PRE_CONFIGURE_HOOKS += ERLANG_RUN_AUTOCONF
>   HOST_ERLANG_DEPENDENCIES += host-autoconf
>   HOST_ERLANG_PRE_CONFIGURE_HOOKS += ERLANG_RUN_AUTOCONF
>   
> -# Whenever updating Erlang, this value should be updated as well, to the
> -# value of EI_VSN in the file lib/erl_interface/vsn.mk
> -ERLANG_EI_VSN = 3.13.2.2
> +# Return the EIV (Erlang Interface Version, EI_VSN)
> +# $(1): base directory, i.e. either $(HOST_DIR) or $(STAGING_DIR)/usr
> +erlang_ei_vsn = `sed -r -e '/^erl_interface-(.+)/!d; s//\1/' $(1)/lib/erlang/releases/$(ERLANG_RELEASE)/installed_application_versions`

  Since this is only used by rebar-package, I think it should move to pkg-rebar.mk.

>   
>   # The configure checks for these functions fail incorrectly
>   ERLANG_CONF_ENV = ac_cv_func_isnan=yes ac_cv_func_isinf=yes
> diff --git a/package/pkg-rebar.mk b/package/pkg-rebar.mk
> index e4e3f3bb6c..4b993dd970 100644
> --- a/package/pkg-rebar.mk
> +++ b/package/pkg-rebar.mk
> @@ -32,10 +32,10 @@ REBAR_TARGET_DEPS_DIR = $(STAGING_DIR)/usr/share/rebar/deps
>   #
>   REBAR_HOST_DEPS_ENV = \
>   	ERL_COMPILER_OPTIONS='{i, "$(REBAR_HOST_DEPS_DIR)"}' \
> -	ERL_EI_LIBDIR=$(HOST_DIR)/lib/erlang/lib/erl_interface-$(ERLANG_EI_VSN)/lib
> +	ERL_EI_LIBDIR=$(HOST_DIR)/lib/erlang/lib/erl_interface-$(call erlang_ei_vsn,$(HOST_DIR))/lib

  Since we support only one erlang version, we could just as well put

$(wildcard $(HOST_DIR)/lib/erlang/lib/erl_interface-*/lib)

or does that directory not necessarily exist yet after erlang has been installed?

  Regards,
  Arnout


>   REBAR_TARGET_DEPS_ENV = \
>   	ERL_COMPILER_OPTIONS='{i, "$(REBAR_TARGET_DEPS_DIR)"}' \
> -	ERL_EI_LIBDIR=$(STAGING_DIR)/usr/lib/erlang/lib/erl_interface-$(ERLANG_EI_VSN)/lib
> +	ERL_EI_LIBDIR=$(STAGING_DIR)/usr/lib/erlang/lib/erl_interface-$(call erlang_ei_vsn,$(STAGING_DIR)/usr)/lib
>   
>   ################################################################################
>   # Helper functions
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/erlang: do not hard-code the Erlang Interface Version (EI_VSN)

[Yann E. MORIN]

Arnout, All,

On 2023-02-14 22:30 +0100, Arnout Vandecappelle spake thusly:
> On 10/02/2023 22:55, Yann E. MORIN wrote:
[--SNIP--]
> >Although both the host and target erlang are the same, we still look
> >into the corresponding file to extract the version. This is so that it
> >would be easier if in the future we ever manage to rely on a
> >system-installed erlang that could have a EI_VSN different from the
> >target one.

This ^^^ [0] ...

[--SNIP--]
> >@@ -36,9 +36,9 @@ ERLANG_PRE_CONFIGURE_HOOKS += ERLANG_RUN_AUTOCONF
> >  HOST_ERLANG_DEPENDENCIES += host-autoconf
> >  HOST_ERLANG_PRE_CONFIGURE_HOOKS += ERLANG_RUN_AUTOCONF
> >-# Whenever updating Erlang, this value should be updated as well, to the
> >-# value of EI_VSN in the file lib/erl_interface/vsn.mk
> >-ERLANG_EI_VSN = 3.13.2.2
> >+# Return the EIV (Erlang Interface Version, EI_VSN)
> >+# $(1): base directory, i.e. either $(HOST_DIR) or $(STAGING_DIR)/usr
> >+erlang_ei_vsn = `sed -r -e '/^erl_interface-(.+)/!d; s//\1/' $(1)/lib/erlang/releases/$(ERLANG_RELEASE)/installed_application_versions`
>  Since this is only used by rebar-package, I think it should move to pkg-rebar.mk.

I also thought about that, but the knowledge where the file is installed
is in erlang, so it makes sense that erlang exports away its own
version, like the variable was set previously.

That's also what we do for AUTOCONF, AUTORECONF, AUTOMAKE et al: they
are defined in their respective packages, but used in the
autotools-package infra.

> >  # The configure checks for these functions fail incorrectly
> >  ERLANG_CONF_ENV = ac_cv_func_isnan=yes ac_cv_func_isinf=yes
> >diff --git a/package/pkg-rebar.mk b/package/pkg-rebar.mk
> >index e4e3f3bb6c..4b993dd970 100644
> >--- a/package/pkg-rebar.mk
> >+++ b/package/pkg-rebar.mk
> >@@ -32,10 +32,10 @@ REBAR_TARGET_DEPS_DIR = $(STAGING_DIR)/usr/share/rebar/deps
> >  #
> >  REBAR_HOST_DEPS_ENV = \
> >  	ERL_COMPILER_OPTIONS='{i, "$(REBAR_HOST_DEPS_DIR)"}' \
> >-	ERL_EI_LIBDIR=$(HOST_DIR)/lib/erlang/lib/erl_interface-$(ERLANG_EI_VSN)/lib
> >+	ERL_EI_LIBDIR=$(HOST_DIR)/lib/erlang/lib/erl_interface-$(call erlang_ei_vsn,$(HOST_DIR))/lib

... [0] explains this ^^^, and ...

>  Since we support only one erlang version, we could just as well put
> $(wildcard $(HOST_DIR)/lib/erlang/lib/erl_interface-*/lib)

... [0] answers that, I believe. ;-)

> or does that directory not necessarily exist yet after erlang has been installed?

The directory does exist, as erl_interface is installed by erlang (it is
kind of part of its stdlib, I'd say), and thus is registered by erlang
itself.

Regards,
Yann E. MORIN.

>  Regards,
>  Arnout
> 
> 
> >  REBAR_TARGET_DEPS_ENV = \
> >  	ERL_COMPILER_OPTIONS='{i, "$(REBAR_TARGET_DEPS_DIR)"}' \
> >-	ERL_EI_LIBDIR=$(STAGING_DIR)/usr/lib/erlang/lib/erl_interface-$(ERLANG_EI_VSN)/lib
> >+	ERL_EI_LIBDIR=$(STAGING_DIR)/usr/lib/erlang/lib/erl_interface-$(call erlang_ei_vsn,$(STAGING_DIR)/usr)/lib
> >  ################################################################################
> >  # Helper functions

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] package/erlang: do not hard-code the Erlang Interface Version (EI_VSN)

[Thomas Petazzoni via buildroot]

On Fri, 10 Feb 2023 22:55:48 +0100
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> The note above the erlang version instructs to refer to another note
> further down the file. However, even if it is not too difficult to find,
> it is still located a bit too far away, and the reference is not very
> explicit what note we should look at.
> 
> When we introduced that variable in 6c1d128844c5 (package/erlang: export
> EI_VSN so other packages can use it), the rationale for hard-coding it
> was "to avoid spawning a shell every time the variable is dereferenced".
> 
> However, that can get a bit confusing and hard to follow. Also, that in
> fact spawns a shell only once for each rebar-packages, so the overhead
> is far from being too high.
> 
> The EI_VSN is only used by rebar-package packages, is derefrenced from
> the rebar-infra and not the packages themselves, and is not needed by
> erlang itself (it knows its own EI_VSN), so we can de-hard-code it, and
> rely on build-time detection, by looking in the appropriate file.
> 
> We have two files where we could look:
>   - lib/erl_interface/vsn.mk in the erlang source tree, but it is not
>     installed,
>   - .../lib/erlang/releases/$(ERLANG_RELASE)/installed_application_versions
>     as installed by erlang.
> 
> We use the second one, as it is cleaner, for a package, to look into
> installed files, rather than to look in the source tree of another
> package.
> 
> Although both the host and target erlang are the same, we still look
> into the corresponding file to extract the version. This is so that it
> would be easier if in the future we ever manage to rely on a
> system-installed erlang that could have a EI_VSN different from the
> target one.
> 
> We can't re-use the variable ERLANG_EI_VSN, because it now needs to be
> $(call)-ed with a parameter. Hopefully, external packages that use it
> directly rather than through the rebar infra, are not legion...
> 
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Will Newton <will.newton@gmail.com>
> Cc: Johan Oudinet <johan.oudinet@gmail.com>
> ---
>  package/erlang/erlang.mk | 8 ++++----
>  package/pkg-rebar.mk     | 4 ++--
>  2 files changed, 6 insertions(+), 6 deletions(-)

Arnout provided feedback, you replied to it, Arnout never provided
counter feedback, so: I've applied to next. Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot