Hello, good plan!
Liliana Marie Prikler <liliana.prik...@gmail.com> writes: > At this point the question then becomes what to name this "build" > output and what to put into it besides pkg-config stuff. In Debian, it's a "dev" package, includes .h (C headers), .pc, .a (static libraries). > 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. It's "gir1.2-glib-2.0" in debian, we can add a "gir" output. > 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 think we should have "build" (or "dev") and "typelib" (or "gir"), but not "pkg-config" and "cmake" in most cases. With a "dev" output, we don't need 'propagated-inputs' in other outputs most cases, so reduce the mess for profiles. With a "typelib" output, we can reduce the runtime closure size for packages which don't depends on them. The build time clojure size reduced by "pkg-config" and "cmake" outputs is small.
