Re: Rethinking propagated inputs?

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

Am Sonntag, den 05.09.2021, 22:27 +0200 schrieb Maxime Devos:
> 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.
And IIUC if glib had a "lib" output, glib:lib would be available in the
sandbox instead of glib:out due to the reference by glib:build?  If
that's the case using #:by and "build" outputs might be a preferable
solution, if not for all packages then at least for some.

At this point the question then becomes what to name this "build"
output and what to put into it besides pkg-config stuff.  Particularly
in the land of glib, there also exist typelibs, which can be used as
"build" inputs in the case of Vala or as runtime inputs in the case of
pygobject and other language bindings.  Perhaps this is early
bikeshedding when we'd actually need to code up #:by, but what would be
the better approach here?  Separate "build" into "pkg-config", "cmake"
(for CMake-based package discovery), "typelib" etc. or have one more or
less anonymous blob called "build"?

Greetings