[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Make mutiple packages from outputs (Was: A plan for parameterized packag
From: |
宋文武 |
Subject: |
Make mutiple packages from outputs (Was: A plan for parameterized packages) |
Date: |
Mon, 16 Nov 2020 19:25:16 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
zimoun <zimon.toutoune@gmail.com> writes:
> Dear,
>
> On Sun, 15 Nov 2020 at 21:46, Danny Milosavljevic <dannym@scratchpost.org>
> wrote:
>
>> * Enable/disable building the documentation. I really don't need a 40 MiB
>> manual stored onto a 16 MiB firmware flash chip. If that's better done as an
>> extra output, fair enough.
>
> Related (I hope) is: build packages with several outputs. For instance,
> ’git’ has several 'outputs' ("send-email", "svn", etc.), so the list of
> "inputs" provides e.g., "subversion" even if I am only interested by
> e.g., "git:send-email". This matters about closure.
>
> And it is maybe an occasion to revisit the museum, i.e., the TODO file:
>
> ** extend ‘propagated-build-inputs’ with support for multiple outputs
>
> #+BEGIN_SRC scheme
> (outputs '("out" "include"))
> (propagated-build-inputs
> `(((("i1" ,p1 "o1")
> ("i2" ,p2))
> => "include")
> ("i3" ,p3)))
> #+END_SRC
>
> For one reference:
>
> <https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00284.html>
>
>
> All the best,
> simon
I'd like to suggest another plan: Make every ‘output’ become a <package>
object, so ‘propagated-build-inputs’ doesn’t need to change. Then we’ll
have something like debian’s source/binary packages [1] and archlinux’s
base/split packages [2].
Example:
--8<---------------cut here---------------start------------->8---
(define-public %gtk+
(source-package
(name "gtk+")
(version "3.24.20")
(source ...)
(inputs ...)
(native-inputs ...)
(outputs
`(("out" .
(binary-package
(name "gtk+") ; version inherit from source
(propagated ...) ; per output propagated-inputs here
(native-search-paths ...)
(synopsis ...) ; can override package metadata
(description ...)))
("gtk-update-icon-cache" .
(binary-package
(name "gtk-update-icon-cache")
...))))
(arguments ...)
(home-page ...)
(synopsis ...)
(descirption ...)
(license ...)))
(define-public gtk+
(source-package->binary-package %gtk+ "out"))
(define-public gtk-update-icon-cache
(source-package->binary-package %gtk+ "gtk-update-icon-cache"))
--8<---------------cut here---------------end--------------->8---
[1] https://sources.debian.org/src/gtk+3.0/3.24.23-2/debian/control/
[2]
https://github.com/archlinux/svntogit-packages/blob/packages/gtk3/trunk/PKGBUILD
We'll have to build some compatibility layer with existing ‘package’ and
adjust UI though. I think this is possible and will bring various
benefits!
- Re: A plan for parameterized packages, (continued)
Re: A plan for parameterized packages, zimoun, 2020/11/15
Re: A plan for parameterized packages, Taylan Kammer, 2020/11/15
Re: A plan for parameterized packages, Danny Milosavljevic, 2020/11/15
Re: A plan for parameterized packages, raingloom, 2020/11/15
Re: A plan for parameterized packages, Denis 'GNUtoo' Carikli, 2020/11/19
Re: A plan for parameterized packages, Ludovic Courtès, 2020/11/20
Re: A plan for parameterized packages, zimoun, 2020/11/20
Re: A plan for parameterized packages, Christopher Baines, 2020/11/20
Re: A plan for parameterized packages, Ludovic Courtès, 2020/11/16