Re: Rethinking propagated inputs?

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

Liliana Marie Prikler schreef op zo 05-09-2021 om 21:37 [+0200]:
> > > 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?

The .pc file includes the absolute path to the library and include directories,
so the output "build" with the .pc file has a reference to the output "out"
with the libraries and include headers.  More concretely, take the .pc from
the glib package:

prefix=/gnu/store/98hgv3i6hdqgiq98ldy7rkpdwhah8iq2-glib-2.62.6
libdir=${prefix}/lib
includedir=${prefix}/include
[more stuff]
Requires.private: libpcre >=  8.31
Libs: -L${libdir} -lglib-2.0
Libs.private: -pthread
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include

The (transitive) references of all inputs to the build process are included
in the sandbox.  In this case, if the package has the hypothetical glib:build
among its inputs, the daemon will automatically make glib:out available as well
in the sandbox.

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]