From: 宋文武 <iyzsong@outlook.com>
To: Liliana Marie Prikler <liliana.prikler@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: Rethinking propagated inputs?
Date: Tue, 07 Sep 2021 20:22:09 +0800 [thread overview]
Message-ID: <OSZP286MB0664A666DCB1EDC5003DBDCDA3D39@OSZP286MB0664.JPNP286.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <7522a0488c02f459a02bf0aa9e6a36d9d8f31d0b.camel@gmail.com> (Liliana Marie Prikler's message of "Sun, 05 Sep 2021 23:10:53 +0200")
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.
next prev parent reply other threads:[~2021-09-07 12:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-04 18:24 Rethinking propagated inputs? Liliana Marie Prikler
2021-09-05 0:50 ` Sarah Morgensen
2021-09-05 7:36 ` Liliana Marie Prikler
2021-09-05 9:50 ` Bengt Richter
2021-09-05 10:50 ` Guix Jargon File (WAS: Rethinking propagated inputs?) Liliana Marie Prikler
2021-09-05 14:54 ` Bengt Richter
2021-09-05 15:28 ` Liliana Marie Prikler
2021-09-05 15:53 ` Jonathan McHugh
2021-09-06 4:07 ` Bengt Richter
2021-09-05 10:06 ` Rethinking propagated inputs? Attila Lendvai
2021-09-05 10:56 ` Julien Lepiller
2021-09-05 16:17 ` Maxime Devos
2021-09-05 16:50 ` Liliana Marie Prikler
2021-09-05 19:18 ` Maxime Devos
2021-09-05 19:37 ` Liliana Marie Prikler
2021-09-05 20:27 ` Maxime Devos
2021-09-05 21:10 ` Liliana Marie Prikler
2021-09-07 11:49 ` Maxime Devos
2021-09-07 12:22 ` 宋文武 [this message]
2021-09-06 18:07 ` Maxim Cournoyer
2021-09-06 18:45 ` Liliana Marie Prikler
2021-09-07 19:01 ` Sarah Morgensen
2021-09-08 7:18 ` Liliana Marie Prikler
2021-09-08 8:24 ` iskarian
2021-09-08 22:12 ` Ludovic Courtès
2021-09-08 22:34 ` zimoun
2021-09-08 22:55 ` Liliana Marie Prikler
2021-09-09 9:48 ` Ludovic Courtès
2021-09-16 18:01 ` Hartmut Goebel
2021-09-06 7:32 ` zimoun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OSZP286MB0664A666DCB1EDC5003DBDCDA3D39@OSZP286MB0664.JPNP286.PROD.OUTLOOK.COM \
--to=iyzsong@outlook.com \
--cc=guix-devel@gnu.org \
--cc=liliana.prikler@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.