guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

packages: [PoC] Expand range of objects 'add-input-label' can label


From: elaexuotee
Subject: packages: [PoC] Expand range of objects 'add-input-label' can label
Date: Mon, 17 Jan 2022 19:01:35 +0900
User-agent: mblaze/1.1

Hey Guix!

This is me grubbing around with internals I know nothing about. Here is a quick
and dirty proof-of-concept patch that extends 'add-input-label' to use the
'name' property of plain-file, program-file, etc.

In addition, it also labels auxiliary files, using the same path string one
provides to search-auxiliary-file. This part is the dirtiest, especially since
we cannot make use of %auxiliary-files-path from (gnu packages) since that
would introduce a circular dependency.

The motivation for this arose while recently munging a package to use new-style
inputs. The package's inputs include an auxiliary file and custom program-file
gexp; however, with new-style inputs there is no obvious way to get get access
to these input paths within the build phases:

- Both get the default "_" label; and
- search-input-file only finds files inside store path *directories*.

There potentially a workaround using file-union, but it's clearly friction.

Naive package-writing me wanted one of two things:

1) Ability to mix old, explicit labels with the new labelless inputs, or
2) Labels that come from the gexp name.

The first option is much more general, but somehow I stumbled across the
add-input-label procedure, so went with 2.

What are your thoughts?

Clear unknows to me:

- Is add-input-label in a fast path? This patch significantly increases the
  cases supplied to 'match', which feels like it has the potential to hit
  performance in a bad way.

- Using the 'name' property is kind of obvious, but add-input-label looks
  deliberatly small. Was using 'name' intentionally avoided for some reason?

- Are there other implicit concerns/constraints within guix/packages.scm that I
  am oblivious to?

- etc?

Anyway, by no means do I expect this to get merged, mostly just hoping to learn
something.

Cheers,
B. Wilson


Attachment: txt9nTYVFS7XZ.txt
Description: Text Data


reply via email to

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