GNU bug report logs - #66801
[PATCH] mix-build-system: draft 1

Previous Next

Full log

View this message in rfc822 format

From: Pierre-Henry Fröhring <phfrohring <at> deeplinks.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 66801 <at> debbugs.gnu.org
Subject: [bug#66801] [PATCH v3 01/14] build-system: Add mix-build-system.
Date: Sat, 18 Nov 2023 13:02:14 +0100

** lilyp
I'm not sure whether we really need the GUIX_ prefix here; you'd have to check
whether the justification for GUIX_PYTHONPATH also holds for erlang and
elixir.


*** phf
Replacing "Python" by "Elixir" in
https://guix.gnu.org/manual/en/html_node/Build-Systems.html, we have:
#+begin_quote
For packages that install stand-alone Elixir programs under bin/, it takes
care of wrapping these programs so that their GUIX_ERL_LIBS environment
variable points to all the compiled Elixir and Erlang libraries they depend
on.
#+end_quote
This seems reasonable for Elixir stand-alone programs.


#+begin_quote
Which Elixir package is used to perform the build can be specified with the
#:elixir parameter. This is a useful way to force a package to be built for a
specific version of the Elixir interpreter, which might be necessary if the
package is only compatible with a single interpreter version.
#+end_quote
Reading: https://hexdocs.pm/elixir/1.15.7/compatibility-and-deprecations.html,
this seems reasonable too.


This seems to point to GUIX_ERL_LIBS rather than ERL_LIBS.


** lilyp
Anyhow, assuming that elixir and erlang code can be used interchangeably by
each once compiled, you should use a single (GUIX_)?ERL_LIBS in both packages.
You might also see whether we could use a single path instead of needing the
lib/erlang and lib/elixir split, but I leave that up to you.


*** phf
"elixir and erlang code can be used interchangeably by each once compiled" is
true because: "Elixir compiles into BEAM byte code (via Erlang Abstract
Format). This means that Elixir code can be called from Erlang and vice versa,
without the need to write any bindings." See:
https://elixir-lang.org/crash-course.html#adding-elixir-to-existing-erlang-programs


Ha… finally, we see that things should change on the Erlang side too.
According to
https://hexdocs.pm/elixir/1.15.7/compatibility-and-deprecations.html, to a
version of Elixir are associated with a few versions of compatible
Erlang/OTP. Since the Elixir package mentions a particular version of Erlang,
then it means that we have X.Y version of Elixir and U.V version for Erlang.
If we have a single path like lib/beam/A.B, then A.B is rather ambiguous.  If
instead we have lib/erlang/U.V and lib/elixir/X.Y, then no ambiguities.


This seems to point to lib/erlang/U.V and lib/elixir/X.Y.

Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.