guix-devel
[Top][All Lists]
Advanced

[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’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]