Liliana Marie Prikler schreef op zo 05-09-2021 om 23:10 [+0200]: > 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 a package has the proposed 'glib:build' in its (propagated-)inputs, and if 'glib' had a 'lib' output, then in the build sandbox of the package, 'glib:lib' will be available. > 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"? I don't know (-:. Maybe let's just start with pkg-config and #:by? for now? The name can always be changed later. Greetings, Maxime.