[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guix.el & multiple outputs
From: |
Taylan Ulrich Bayirli/Kammer |
Subject: |
Re: guix.el & multiple outputs |
Date: |
Sun, 07 Sep 2014 00:39:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
address@hidden (Ludovic Courtès) writes:
> Are you suggesting that it should instead show it as two lines?
>
> gcc-toolchain 4.9.1 out yes Complete GCC tool chain for
> C/C++ development
> gcc-toolchain 4.9.1 debug yes Complete GCC tool chain for
> C/C++ development
>
> I think I would prefer it. (One advantage is that it would allow users
> to mark just one specific output, which is not currently possible.)
Indeed, it lifts the whole need for separate key-bindings to choose a
non-standard output. Can't think of any downsides either; maybe just
making the list longer.
> Conceptually, this is similar to the distinction between “binary”
> packages and “source” packages in distros like Debian.
>
> Technically, the main reason why things are this way is that in most
> cases it’s not possible to have separate build processes (and thus
> separate <package> objects) producing the various outputs, in part
> because byproducts contain hard-coded file names, which makes them
> non-relocatable.
>
> An obvious example is the “debug” output. Another is packages that
> produce both shared libraries and programs linked against those libs:
> what shared lib would appear in the RUNPATH of the executables?
Thanks for the explanation. :)
So as I understand it, while it would be possible --in an "everything is
possible" sense-- to change the system in such a way that separate
<package>s would use the same build process, the effort/benefit ratio is
too bad.
In that case, let me just mention a concrete annoyance I had which could
be fixed on the UI side: I find it useful to keep a plain text list of
all installed packages, in a format that can also be fed back in. So
far I used "guix package -I | awk '{print $1}'", but that doesn't handle
outputs. A little AWK hackery could do it, but parsing that output is
probably wrong to begin with. Maybe a --machine-readable flag could be
added, which would ideally list alternate outputs in the foo:bar format
so they can directly be fed back in.
Taylan
- guix.el: Key bindings for a "package list", Alex Kost, 2014/09/05
- Re: guix.el: Key bindings for a "package list", Ludovic Courtès, 2014/09/05
- Re: guix.el: Key bindings for a "package list", Alex Kost, 2014/09/05
- Re: guix.el: Key bindings for a "package list", Ludovic Courtès, 2014/09/05
- Re: guix.el: Key bindings for a "package list", Alex Kost, 2014/09/06
- Re: guix.el: Key bindings for a "package list", Taylan Ulrich Bayirli/Kammer, 2014/09/06
- guix.el & multiple outputs, Ludovic Courtès, 2014/09/06
- Re: guix.el & multiple outputs,
Taylan Ulrich Bayirli/Kammer <=
- Re: guix.el & multiple outputs, Ludovic Courtès, 2014/09/08
- Re: guix.el & multiple outputs, Alex Kost, 2014/09/07
- Re: guix.el & multiple outputs, Alex Kost, 2014/09/19
- Re: [PATCH] emacs: Rewrite scheme side in a functional manner., Ludovic Courtès, 2014/09/20
- Re: [PATCH] emacs: Rewrite scheme side in a functional manner., Alex Kost, 2014/09/21
- Re: [PATCH] emacs: Rewrite scheme side in a functional manner., Ludovic Courtès, 2014/09/21
- Re: [PATCH] emacs: Rewrite scheme side in a functional manner., Alex Kost, 2014/09/23
- Re: [PATCH] emacs: Rewrite scheme side in a functional manner., Ludovic Courtès, 2014/09/24
- ‘profile-generations’, Ludovic Courtès, 2014/09/21
- Re: guix.el & multiple outputs, Ludovic Courtès, 2014/09/21