[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: search-input-file vs (assoc-ref inputs)
From: |
Ludovic Courtès |
Subject: |
Re: search-input-file vs (assoc-ref inputs) |
Date: |
Sat, 08 Jan 2022 22:10:34 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi,
Zhu Zihao <all_but_last@163.com> skribis:
> Some of my concern about label-less style inputs.
>
> 1. How can we refer to a non-package input? Some code might use
> something like
>
> (inputs
> `(("xxxx.patch" ,(origin ....))))
You can either keep labels or, what I would recommend, use gexps and
‘local-file’. An example of that is commit
a21590dabfcef0aa008503ea981364b90750b07c.
> If I want to replace this patch, I can simply use list operations from
> SRFI-1 to manipulate it. But in label-less style, there's no label for a
> <origin> object. Packagers may try to embed these objects into the build
> expression using `ungexp`. But I think it violates the dependency
> inversion principle(We don't rely on label, but rely on concrete
> object).
That’s true. OTOH, I think one rarely wants to override a patch because
the patch is usually closely tied to the ‘source’ origin anyway.
But yeah, if you have a concrete example, we could see how well that
works there.
> 2. libgcc, libgcc is a specific output of gcc. IIUC in build expression,
> it shares label with gcc, gcc is an implicit input in many build
> system. It's not so convenience for me to refer libgcc.
>
> For example, I want to set up the `LD_LIBRARY_PATH` for testing. it's
> better to use `(string-append (this-package-inputs "libgcc") "/lib")`.
> But I can't do this, the label of libgcc is "hidden".
> `search-input-directory` doesn't work here because "/lib" is a common
> directory exists in many package. I have to write `(dirname
> (search-input-file input "libstdc++.so.6"))`, so ugly...
I’d do (dirname (search-input-file input "/lib/libstdc++.so.6")).
That’s not pretty, but I wouldn’t call it “ugly” either. :-)
Before that, you would refer to a label that doesn’t actually appear in
the package’s input (because GCC is an implicit input), which wasn’t
better IMO.
As I wrote back in <https://issues.guix.gnu.org/49169>, there are idioms
we used before and that don’t have an obvious or pleasant translation in
the label-less style. I think we should look together at those concrete
examples when we find them and see what we can come up with.
Thanks for your feedback!
Ludo’.