Re: Rethinking propagated inputs?

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

Am Sonntag, den 05.09.2021, 21:18 +0200 schrieb Maxime Devos:
> [...]
> [Liliana Marie Prikler schreef op zo 05-09-2021 om 18:50 [+0200]:]
> > This does cause problems with language bindings though,
> > e.g. pygobject, as those also propagate the package in question and
> > can't be neatly separated.
> 
> python-pygobject can just keep everything in the output "out",
> and let glib and libffi be propagated by "out", no?  I don't see
> how this would cause trouble for language bindings.
It doesn't immediately cause problems with the language bindings
themselves, you are correct about that, but since packages using such
bindings must by virtue of being python packages already propagate all
their inputs we are back at square zero, so to speak.  However, perhaps
we can solve that by putting launchers in the "bin" output?

> > > Now, imagine the "build" output of "zile" had glib:build in
> > > propagated-inputs, using the scheme described above.  Then, if
> > > the "out" output of zile is installed in a profile, that doesn't
> > > cause glib to appear in the profile as well, because glib is only
> > > propagated for the "build" output of zile, and not for "out"
> > > output of zile.
> > > 
> > > However, if "build" is installed in the profile (e.g. because
> > > someone runs "guix environment --ad-hoc zile:build various
> > > compilation tools" to create an application using the zile
> > > library), then the .pc becomes available in the profile. 
> > I must admit that this solution appears to have some surface
> > elegance, but what exactly would go in the "build" output of a
> > package?  You mentioned pkg-config files (obviously), but those
> > don't suffice to actually build a package, do they?
> 
> Sometimes they do suffice.  The .pc files contain the "-L/.../LIB",
> "-I/.../include" and "-lstuff" flags needed for compilation.  If the
> build system of the package uses pkg-config, it will use those flags,
> so the compiler will find the library in that case.
> 
> Not sure if they always do suffice.
Is that so?  I would think the build process needs to see stuff outside
of its inputs for that to work, e.g. the actual header it wants to
include, which isn't part of "build".  Am I misunderstanding our
sandbox requirements?

> > Would we need an extra syntax to e.g. propagate the "out" output by
> > "build" (and in some cases the "lib" output instead)?
> 
> Not if .pc files are put in "out" (or "lib" in some cases) instead of
> the originally proposed "build", but otherwise, possibly?
Okay, let's talk about the other things then until we can put a certain
(as in "sure to be correct") answer to this question.

Greetings