guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#66801] [PATCH va3e5ae0f..37252e07 01/32] rebar-build-system and pac


From: Liliana Marie Prikler
Subject: [bug#66801] [PATCH va3e5ae0f..37252e07 01/32] rebar-build-system and packages.
Date: Mon, 30 Oct 2023 06:29:32 +0100
User-agent: Evolution 3.46.4

Am Sonntag, dem 29.10.2023 um 23:14 +0100 schrieb Pierre-Henry
Fröhring:
> n [PATCH v2]. So this time, it will be [PATCH v3].
> 
> > Emacs, Rust, etc., build systems just strip out the prefix.  No
> > need to go all fancy regexpy :)何で?
> 
> WAITING: Well, it makes the warning message completely explicit, for
> example:
> ┌────
> │ AssertionWarning 4dcbff27
> │   Assertion: re matches name.
> │     re = ^erlang-(.*)
> │     name = something-else
> └────
> Is it OK if it stays like this?
You can use a shorter error and explain the problem better: 
  "~a does not start with \"erlang-\"" name

> 
> > Uhm, how are you improving the status quo here?
> 
> WAITING: comment updated with:
> ┌────
> │ ;;   If these directories exist, then no error occurs. So, we make
> sure
> │ ;;   they exist.
> └────
> Is this OK?
> 
> 
> [...]
> > 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.
> 
> WAITING: 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?
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.  

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.

> > Also, IIUC, erlang-depends already does something rather similar. 
> > Is there any reason it's broken for you?
> 
> WAITING: Without that (i.e., _checkouts/lib-name/src), rebar3 will
> not compile things. Is this a satisfaying explaination?
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

Cheers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]