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

Previous Next

Full log

Message #131 received at 66801 <at> debbugs.gnu.org (full text, mbox):

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: Re: [PATCH va3e5ae0f..37252e07 01/32] rebar-build-system and packages.
Date: Mon, 30 Oct 2023 13:30:23 +0100

[Message part 1 (text/plain, inline)]

I've collected your comments in an org-file so that it's easier (at least
for me, but I hope it's the case for you too)
to follow multiple discussions at the same time. I've only included the
ones that are still open to discussion.
The structure should be self-evident. The most important comment may be
Comment 9.
Cheers.

* TODO Comment 4
** LMP
This reeks of the hack that we need for cargo-build-system, except with a
worse variable name.  I strongly suggest looking into ways we can do without
it.

** PHF
This idea came from a discussion with jpoiret. See:
https://logs.guix.gnu.org/guix/2023-10-24.log#180111. It seems that the idea
you suggest is to use =search-path-as-list= as hinted below (=Comment 9=).
Is this
correct?

* TODO Comment 6
** LMP
Uhm, how are you improving the status quo here?

** PHF
Comment updated with:
#+begin_example
;;   If these directories exist, then no error occurs. So, we make sure
;;   they exist.
#+end_example
Is this OK?

I don't see how to prevent rebar3 to do that. It's apparently an opened
issue:
https://github.com/erlang/rebar3/issues/1173

* TODO Comment 9
** LMP
You might want to look into possible PATH variables or put these sources
into
a special folder so that you can use search-path-as-list.

** PHF
Perhaps an idea:
  1) If we require all Erlang packages to have an output “src” something
like: /gnu/store/…elixir-pkg-1.2.3/src/elixir/src/…,
  2) then (search-path-as-list '("src/elixir/src")
'("/gnu/store…elixir-pkg-1.2.3" …)) would return
'("/gnu/store…elixir-pkg-1.2.3/src/elixir/src" …) ≡ lst-src.
  3) Given lst-src, it would be enough to install each source under
_checkouts,
     i.e., _checkouts/lib-name/src. It is probably feasible to retrieve
lib-name
     from somewhere.
What do you think?

** LMP
Rather than require, you can add a phase to ensure that this is the case.
I'm not sure whether we should make that an extra output, however; there
might be many packages for which we don't need those sources and where we do
need them, we could potentially add them as native-inputs.

** PHF
Agreed.

** LMP
Another alternative would be to keep the sources in
=lib/erlang/lib/lib-name/src= so that it gets symlinked by the phase we
have.
Though at that point we can surely go with a less surprising install
directory.

** PHF
Here is the approach taken so far:
1) The objective is to ensure that =mix compile= does not attempt to use the
   network and, as a result, fails to compile.
2) For the above to be true, it is necessary to have — at build time — the
   sources of all Erlang input packages and install them as checkouts.
3) Thus, the question becomes: How to access all the Erlang package sources
at
   build time?
4) One idea was to have the client side of the build code send all the
sources
   to the server through the poorly named argument =#:sources-erlang=. This
led
   to the current code. It relies on the fact that for a given Erlang
package,
   it is possible to access its source in the store, for example,
   =/gnu/store/…erlang-kv/erlang-kv.tar=.
5) Instead, you propose modifying the installation process so that sources
are
   installed along with the built libraries. The source might be collected
   with =search-path-as-list=.

   The downside seems to be that the source code is stored twice: first in
the
   archive, then in the package.

   However, this could lead to a much cleaner method of passing the sources
to
   the build-side code, that is, the source code would not be passed through
   =arguments=.

I'm sending a patch based on this latter idea. Are you OK with that?

* TODO Comment 10
** LMP
Also, IIUC, erlang-depends already does something rather similar.  Is there
any reason it's broken for you?

** PHF
Without that (i.e., _checkouts/lib-name/src), rebar3 will not compile
things. Is this a satisfying explanation?

** LMP
I mean, ideally we would store these things in some other directory,
given that _checkouts/lib-name already contains the precompiled stuff
after erlang-depends.  However, if the tooling insists on storing both
in the same place, you could simply amend the existing erlang-depends
phase to:
1. Copy instead of symlinking
2. Also copy the sources

** PHF
If I understand correctly, this should be addressed with the patch from
=Comment 9= section above.

[Message part 2 (text/html, inline)]

Previous Next

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