Re: search-input-file vs (assoc-ref inputs)

[Zhu Zihao <all_but_last@163.com>]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

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 ....))))

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).

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

-- 
Retrieve my PGP public key:

  gpg --recv-keys D47A9C8B2AE3905B563D9135BE42B352A9F6821F

Zihao

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]