[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rethinking propagated inputs?
From: |
Liliana Marie Prikler |
Subject: |
Re: Rethinking propagated inputs? |
Date: |
Sun, 05 Sep 2021 09:36:30 +0200 |
User-agent: |
Evolution 3.34.2 |
Am Samstag, den 04.09.2021, 17:50 -0700 schrieb Sarah Morgensen:
> Hi Liliana,
>
> (Efraim, I've Cc'd you since you're working on re-doing Rust inputs.)
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>
> > Does anyone have an idea how we should handle propagations for the
> > sake of pkg-config? Perhaps we could add "linked-inputs", which
> > are added when building packages and environments when not using --
> > ad-hoc, but not when union-building profiles. WDYT?
>
> I know nothing about pkg-config, but such an input would help
> simplify things for Go (and I think for Rust) since many inputs need
> to be propagated only at build-time.
To be fair, I wasn't not thinking about Go and Rust, which at least on
the surface appear to have similar propagation semantics. I do however
not know whether all currently propagated inputs from those two could
be reclassified as linked-inputs. FWIW I don't think (most) Emacs,
Python or Guile packages work that way, but I do know of at least one
that would profit from having linked-inputs.
> What do you think of "build-propagated-inputs"?
We don't call things build-inputs here in Guix land, that's a no-no :P
> (A quick search of the ML turned up one previous discussion [0]; does
> anyone know of others?)
>
> [0]
> https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00362.html
W.r.t. native-inputs, I think native-inputs should propagate
propagated-inputs, but not linked-inputs. Makes sense, doesn't it?
Re: Rethinking propagated inputs?, Maxime Devos, 2021/09/05