Re: Rethinking propagated inputs?

[宋文武]

Hello, good plan!


Liliana Marie Prikler <liliana.prikler@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.