Re: Rethinking propagated inputs?

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

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?