From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Will Newton <will.newton@gmail.com>,
Johan Oudinet <johan.oudinet@gmail.com>,
buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH] package/erlang: do not hard-code the Erlang Interface Version (EI_VSN)
Date: Thu, 10 Aug 2023 23:16:38 +0200 [thread overview]
Message-ID: <20230810231638.6837c8da@windsurf> (raw)
In-Reply-To: <20230210215548.1050371-1-yann.morin.1998@free.fr>
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
prev parent reply other threads:[~2023-08-10 21:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 21:55 [Buildroot] [PATCH] package/erlang: do not hard-code the Erlang Interface Version (EI_VSN) Yann E. MORIN
2023-02-14 21:30 ` Arnout Vandecappelle
2023-02-15 6:29 ` Yann E. MORIN
2023-08-10 21:16 ` Thomas Petazzoni via buildroot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230810231638.6837c8da@windsurf \
--to=buildroot@buildroot.org \
--cc=johan.oudinet@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=will.newton@gmail.com \
--cc=yann.morin.1998@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.