From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 4C4nOL5bVmXmIAAA9RJhRA:P1 (envelope-from ) for ; Thu, 16 Nov 2023 19:13:19 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 4C4nOL5bVmXmIAAA9RJhRA (envelope-from ) for ; Thu, 16 Nov 2023 19:13:18 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5CF3C142FC for ; Thu, 16 Nov 2023 19:13:18 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=deeplinks-com.20230601.gappssmtp.com header.s=20230601 header.b=nYS6I0wW; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1700158398; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:resent-cc:resent-from:resent-sender: resent-message-id:in-reply-to:in-reply-to:references:references: list-id:list-help:list-unsubscribe:list-subscribe:list-post: dkim-signature; bh=latFGSEXK/UMkxwgkEsNnhns4EKLhmr2m1YHMW17g6I=; b=mwO1AvtQTB0hvE8vIrGbK4pT6ZqU9OlSiq0Hxa39WF3zvisy76+8FK38pKk26Ks3zLnOxO S6pWg1zhdhJFHNglonTzMT4+o3Bb8JU24Z4q6Ww8P3+E/hnMespFp6epQP/Hhv9Jgxknyw qXk9T7wwM5cBCy5K8X0FsN1uI4fwphEQ8CnVtnJS1v9eWqx2Nn4seC77G/k8nOu+kA2Bx+ hZSyTuN5rowpmRWWsN7HnzzJ2opHbf7fSgVkH4XbF9Stpo59RhaUdOTrUNqeOzTwpHyKnI XOMSknZifyY6cyXLyMl9ge79x5qPdxgwO/DI9BJ00j2VQDW9wJSxF+dkp7G7fg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=deeplinks-com.20230601.gappssmtp.com header.s=20230601 header.b=nYS6I0wW; spf=pass (aspmx1.migadu.com: domain of "guix-patches-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-patches-bounces+larch=yhetil.org@gnu.org"; dmarc=none ARC-Seal: i=1; s=key1; d=yhetil.org; t=1700158398; a=rsa-sha256; cv=none; b=lcmdiq1xpa+HXkuCc2by9SU0iOsfkMkyGgXhm6XqJplw3FnT+S2Bp8FKRQa82Ab0Wfiq7x QPYRf8MatBbBwdLBtE2Qvwbnemi67EeFqSuBZi/ALfsqI6fg/OLzYNtEMoFfQp5JOBvj4v FKqTGImCqxmSekiMDje89LjlvplILhvwjQfkrcIGBNVRGyL82pw3f0bbPjMKOguFeVUTPb vMzKYR9C22P/l7sw8yacmr8KMr4GdbGMmFwz9zvEOLe1Yjxn8L/672Q3XFDDEuD9rToGOk cWQVJXhcEjkpuZFhpb4wS3Ez/YmFFk2nYHAkjcSgdzDC7iteB1IdbCx9aeQnRw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3grW-0002jc-FP; Thu, 16 Nov 2023 13:13:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r3grQ-0002iU-H9 for guix-patches@gnu.org; Thu, 16 Nov 2023 13:13:04 -0500 Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r3grP-0006EQ-Ba for guix-patches@gnu.org; Thu, 16 Nov 2023 13:13:04 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r3grO-0001in-Hc for guix-patches@gnu.org; Thu, 16 Nov 2023 13:13:02 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#66801] [PATCH v3 01/14] build-system: Add mix-build-system. Resent-From: Pierre-Henry =?UTF-8?Q?Fr=C3=B6hring?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 16 Nov 2023 18:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66801 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 66801@debbugs.gnu.org Cc: Liliana Marie Prikler Received: via spool by 66801-submit@debbugs.gnu.org id=B66801.17001583446564 (code B ref 66801); Thu, 16 Nov 2023 18:13:02 +0000 Received: (at 66801) by debbugs.gnu.org; 16 Nov 2023 18:12:24 +0000 Received: from localhost ([127.0.0.1]:44472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3gql-0001ho-9D for submit@debbugs.gnu.org; Thu, 16 Nov 2023 13:12:23 -0500 Received: from mail-yb1-xb30.google.com ([2607:f8b0:4864:20::b30]:57443) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3gqi-0001hX-S5 for 66801@debbugs.gnu.org; Thu, 16 Nov 2023 13:12:21 -0500 Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-d852b28ec3bso1137480276.2 for <66801@debbugs.gnu.org>; Thu, 16 Nov 2023 10:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deeplinks-com.20230601.gappssmtp.com; s=20230601; t=1700158335; x=1700763135; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=latFGSEXK/UMkxwgkEsNnhns4EKLhmr2m1YHMW17g6I=; b=nYS6I0wWUI/4MQ/U7BYraFMcbhtt1D2/2MeIgqfHctfC2n8CNGLL9PD/L1VpeexDTO Imeq6PNsCreyfqrsEHRlrBym/RgtzhuaIfikWJkZ0pMfL9uP4h9YYgECVWBP6m35W8T3 kXUa88+4GPRrt09jKS5arkGzDAFerhzxRh8AYkvCr7EuhBxJl3r+dLdXgXrangS6hJHr NKmDl4h2FOanr654L4bBloQ3h6IAO9pSYhBTGCVQE91jGfOUwbRQJX57s1BBpS2nt/Io ApjEPG8/HLCMLh1HFzQcuw0hlEcqstrWuLdrhqrlTG/V2zO1Q+2xkE1Z2GkFnCh39gKq y/og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700158335; x=1700763135; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=latFGSEXK/UMkxwgkEsNnhns4EKLhmr2m1YHMW17g6I=; b=c5y2egP22plMXnHnXW7YkvZ8ng8/8H1zC0jIsC5mcBkGWB9gLpvZfuhzd/CWZ9LExs uQ4QTqbunR9avj30N+9muT4BXr+26/XtB8w9MQ8PgFSQ3/q3C25H7oDOf708B+4eqJfr PEx7yUVgXaU200+B2reMu1VGp7NzJZ/uEc9UOi13TwlY7SBPFRC9BfxI6wVyyNYDwHkr gehNjGf6BGujhiS0Oo2tL2jDn4IgQFTOtVP1cYu1N9BxXGIJstZz/jSaYY3uY93g/pR0 LwVVA5VVLj1QuQlNn9cmNWpPEL9d2UG4B3xY7Gmiz/5m9qRT7ytn6mAPmjhmNdanv4Nk 7B/Q== X-Gm-Message-State: AOJu0YzwPvGVYRIcnO22HOQ58n3naKpjkO/+wh3Gfsg/eL7s+EyP4Crt y4VOi3NUOJLYrV7MfdO/riaSavuXtopBTtGH2oZEMzci83cmBSlJMss= X-Google-Smtp-Source: AGHT+IHtVaLV5B1vX68+yQMEcapTfGP8H/9LX8GKjTE/V6A7X0Gk2vqmCgYYq4axWFW5Wx+4NW6KbT2SkHdeZz+/IJs= X-Received: by 2002:a25:1ed5:0:b0:dae:e7d8:26f0 with SMTP id e204-20020a251ed5000000b00daee7d826f0mr14933652ybe.54.1700158334831; Thu, 16 Nov 2023 10:12:14 -0800 (PST) MIME-Version: 1.0 References: <67c324d191a9698aed8d9887260cb0ef2bc031df.1700088189.git.phfrohring@deeplinks.com> <66cf8aa37e2c9696af3a8895059b9293669f485c.camel@gmail.com> In-Reply-To: <66cf8aa37e2c9696af3a8895059b9293669f485c.camel@gmail.com> From: Pierre-Henry =?UTF-8?Q?Fr=C3=B6hring?= Date: Thu, 16 Nov 2023 19:12:04 +0100 Message-ID: Content-Type: multipart/alternative; boundary="0000000000009c2372060a48f586" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: guix-patches-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -1.09 X-Spam-Score: -1.09 X-Migadu-Queue-Id: 5CF3C142FC X-Migadu-Scanner: mx13.migadu.com X-TUID: JjdVoEFFX4j/ --0000000000009c2372060a48f586 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I should really configure mu4e or something like that. I'm curious to know if you have a pointer to an efficient setup for working through emails like this. Below the last three comments: * WAITING Comment :PROPERTIES: :ID: 76abe0e4-a0e2-4176-bdc0-9ff241e8ba42 :END: ** lilyp > +(define (elixir-libdir elixir path) > + "Return the path where all libraries for a specified ELIXIR > version are installed." > + (string-append path "/lib/elixir/" (elixir-version elixir))) You probably want to swap path and elixir and perhaps also find a way to implicitly parameterize the latter so as to make it optional. ** phf Is this what you mean? #+begin_src scheme ;; The Elixir version is constant as soon as it is computable from the current ;; execution. It is a X.Y string where X and Y are respectively the major and ;; minor version number of the Elixir used in the build. (define elixir-version (make-parameter "X.Y")) (define* (elixir-libdir path #:optional (version (elixir-version))) "Return the path where all libraries for a specified ELIXIR version are installed." (string-append path "/lib/elixir/" version)) (define* (configure #:key inputs mix-path mix-exs #:allow-other-keys) =E2=80=A6 (elixir-version (receive (_ version) (package-name->name+version (strip-store-file-name (assoc-ref inputs "elixir"))) (let* ((components (string-split version #\.)) (major+minor (take components 2))) (string-join major+minor "."))))) #+end_src ** lilyp I'd use %elixir-version and perhaps make it a fluent rather than a paramete= r (not quite sure whether parameters get reset when a function goes out of scope). ** phf Parameters do not get reset when a function goes out of scope: #+begin_src scheme (define x (make-parameter 1)) (define (set-x-to-2) (x 2)) (format #t "~a~%" (x)) (set-x-to-2) (format #t "~a~%" (x)) #+end_src #+begin_example 1 2 #+end_example The [[ https://www.gnu.org/software/guile/manual/html_node/Parameters.html][docume= ntation]] seems to indicate that it's an appropriate replacement for a global variable. * WAITING Comment ** lilyp Is hex not an (implicit) native-input in your build system? Anything that keeps it from functioning is a packaging bug imho. ** phf If ~mix~ finds ~Hex~ under ~$MIX_ARCHIVES/hex/hex~, then ~mix compile~ does not emit the message above. I'm not sure how could this be changed. I've tried to se= t ~MIX_PATH~ to ~/gnu/store/=E2=80=A6-elixir-hex-2.0.5/lib/elixir/1.14~ witho= ut success. So, this is the reason why ~install-hex~ phase installs Hex like it does. * WAITING Comment ** lilyp > + (define (install-inputs mix-env) > + (for-each (cut install-input mix-env <>) > + (append inputs native-inputs))) Installing native inputs: probably a bad idea (inhibits cross- compilation). ** phf A slight variant that does not link things when it should not: #+begin_src scheme (define (install-inputs mix-env) (for-each (cut install-input mix-env <>) (cond ((string=3D? mix-env "prod") inputs) ((member mix-env '("shared" "test")) (append inputs native-inputs)) (else (error (format #f "Unexpected Mix env: ~a~%" mix-env)))))) #+end_src I did not consider cross-compilation yet. The following might be wrong be here we go. I far as I understand, Erlang applications are largely platform independent. Once the code is compiled to BEAM bytecode, it can run on any platform that has the Erlang VM installed. If an Erlang library uses native extensions, then cross-compilation might be required. For a build to succee= d in a given environment (one of "prod", "test", "shared"), the BEAM files of all dependencies should be present on the build machine. So, all dependencies must be installed ** lilyp Not an expert on elixir, but that sounds borked. ** phf Yes. Did not have time to look into it as of now. ** lilyp You might get around this with propagated-inputs maybe? That being said, native-inputs shouldn't blow up a build if missing. ** phf If ~native-inputs~ are missing, it's fine. But wait, maybe there is a misunderstanding here. Please, check the reasoning: in a cross-compilation context, we have two machines A and B, and: - native-inputs: dependencies that must be built on A for A ; - inputs: dependencies that must be built on A for B ; - propagated-inputs: like inputs but installed in the profile. If installing Elixir (like Python) gathers all libraries in the profile with a variable like ~GUIX_ERL_LIBS~, then, it would be enough to list dependencies (in packages) in ~propagated-inputs~ instead of ~inputs~ and make them available to Elixir through ~ERL_LIBS~ (like ~GUIX_PYTHONPATH~ and ~PYTHONPATH~). As a consequence, the ~install-dependencies~ phase would be reduced to ~ERL_LIBS=3D$GUIX_ERL_LIBS~. Is this an answer to: "You might get around this with propagated-inputs maybe?" --0000000000009c2372060a48f586 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I should really configure mu4e or something like that.
= I'm curious to know if you have a pointer to an efficient setup for wor= king through emails like this.
Below the last three comments:

* W= AITING Comment
:PR= OPERTIES:
:ID: =C2=A0 =C2=A0 =C2=A0 76abe0e4-a0e2-4176-bdc0-9ff241e8ba42=
:END:

** lilyp
> +(define (elixir-libdir elixir path)
&= gt; + =C2=A0"Return the path where all libraries for a specified ELIXI= R
> version are installed."
> + =C2=A0(string-append path = "/lib/elixir/" (elixir-version elixir)))

You probably want= to swap path and elixir and perhaps also find a way
to implicitly param= eterize the latter so as to make it optional.


** phf
Is this = what you mean?
#+begin_src scheme
;; The Elixir version is constant a= s soon as it is computable from the current
;; execution. It is a X.Y st= ring where X and Y are respectively the major and
;; minor version numbe= r of the Elixir used in the build.
(define elixir-version (make-paramete= r "X.Y"))

(define* (elixir-libdir path #:optional (version= (elixir-version)))
=C2=A0 "Return the path where all libraries for= a specified ELIXIR version are installed."
=C2=A0 (string-append p= ath "/lib/elixir/" version))

(define* (configure #:key inp= uts mix-path mix-exs #:allow-other-keys)
=C2=A0 =E2=80=A6
=C2=A0 (eli= xir-version
=C2=A0 =C2=A0(receive (_ version) (package-name->n= ame+version (strip-store-file-name (assoc-ref inputs "elixir")))<= span class=3D"gmail-im" style=3D"color:rgb(80,0,80)">
=C2=A0 =C2=A0 =C2= =A0(let* ((components =C2=A0(string-split version #\.))
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 (major+minor (take components 2)))
=C2=A0 = =C2=A0 =C2=A0 =C2=A0(string-join major+minor ".")))))
#+end_sr= c


** lilyp
I'd use %elixir-version and perhaps make it a fluent rather = than a parameter
(not quite sure whether parameters get reset when a fun= ction goes out of
scope).


** phf
Parameters do not = get reset when a function goes out of scope:
#+begin_src scheme
(defi= ne x (make-parameter 1))
(define (set-x-to-2) (x 2))
(format #t "= ;~a~%" (x))
(set-x-to-2)
(format #t "~a~%" (x))
#+e= nd_src

#+begin_example
1
2
#+end_example

The [[https://www.gnu.org/software/guile/man= ual/html_node/Parameters.html][documentation]] seems to indicate that i= t's an appropriate replacement for a
global variable.


* W= AITING Comment
** lilyp
Is hex not an (impli= cit) native-input in your build system?=C2=A0 Anything that
keeps it fro= m functioning is a packaging bug imho.


** phf
If ~mix~= finds ~Hex~ under ~$MIX_ARCHIVES/hex/hex~, then ~mix compile~ does not emi= t
the message above. I'm not sure how could this be changed. I'v= e tried to set
~MIX_PATH~ to ~/gnu/store/=E2=80=A6-elixir-hex-2.0.5/lib/= elixir/1.14~ without success. So,
this is the reason why ~install-hex~ p= hase installs Hex like it does.


* WAITING Comment
** lilyp
> + =C2=A0(define= (install-inputs mix-env)
> + =C2=A0 =C2=A0(for-each (cut install-inp= ut mix-env <>)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0(append inputs native-inputs)))

Installing native inputs: prob= ably a bad idea (inhibits cross-
compilation).


** phf
A sl= ight variant that does not link things when it should not:
#+begin_src s= cheme
(define (install-inputs mix-env)
=C2=A0 =C2=A0 (for-each (cut i= nstall-input mix-env <>)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 (cond
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ((= string=3D? mix-env "prod") inputs)
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 ((member mix-env '("shared" &quo= t;test")) (append inputs native-inputs))
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (else (error (format #f "Unexpected Mi= x env: ~a~%" mix-env))))))
#+end_src

I did not consider cros= s-compilation yet. The following might be wrong be here
we go. I far as = I understand, Erlang applications are largely platform
independent. Once= the code is compiled to BEAM bytecode, it can run on any
platform that = has the Erlang VM installed. If an Erlang library uses native
ext= ensions, then cross-compilation might be required. For a build to succeed
in a given environm= ent (one of "prod", "test", "shared"), the BE= AM files of
all dependencies should be present on the build machine. So,= all dependencies
must be installed


** lilyp
Not an expert on elixir, bu= t that sounds borked.


** phf
Yes. Did not have time to= look into it as of now.


** lilyp
You might get around this with propagated-input= s maybe?=C2=A0 That being said,
native-inputs shouldn't blow up a bu= ild if missing.


** phf
If ~native-inputs~ are missing,= it's fine. But wait, maybe there is a
misunderstanding here. Please= , check the reasoning: in a cross-compilation
context, we have two machi= nes A and B, and:
- native-inputs: dependencies that must be built on A = for A ;
- inputs: dependencies that must be built on A for B ;
- prop= agated-inputs: like inputs but installed in the profile.


If inst= alling Elixir (like Python) gathers all libraries in the profile with a
= variable like ~GUIX_ERL_LIBS~, then, it would be enough to list dependencie= s (in
packages) in ~propagated-inputs~ instead of ~inputs~ and make them= available to
Elixir through ~ERL_LIBS~ (like ~GUIX_PYTHONPATH~ and ~PYT= HONPATH~). As a
consequence, the ~install-dependencies~ phase would be r= educed to
~ERL_LIBS=3D$GUIX_ERL_LIBS~.


Is this an answer to: = "You might get around this with propagated-inputs
maybe?"

<= /div> --0000000000009c2372060a48f586--