GNU bug report logs - #77708
[PATCH] gexp: ‘with-parameters‘ is respected by caches.

Previous Next

To reply to this bug, email your comments to 77708 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: David Elsing <david.elsing <at> posteo.net>
To: guix-patches <at> gnu.org
Cc: David Elsing <david.elsing <at> posteo.net>
Subject: [PATCH] gexp: ‘with-parameters‘ is respected by caches.
Date: Thu, 10 Apr 2025 14:46:54 +0000

* guix/gexp.scm (lower-object, lower+expand-object):
Use (%parameterized-counter) as additional cache key.
(%parameterized-counter): New parameter.
(%parameterized-counter-next-value): New variable.
(%parameterized-counters): New variable.
(add-parameterized-counter): New procedure.
(compile-parameterized): Add %parameterized-counter to parameters.
* guix/packages.scm (cache!): Use ‘hash-set!‘ instead of ‘hashq-set!‘. Use
`(,(scm->pointer package) . ,(%parameterized-counter)) as key.
(cached, package->derivation, package->cross-derivation):
Use (%parameterized-counter) as additional cache key.
* tests/gexp.scm ("with-parameters for custom parameter"): New test.
---
As noted by Ludo' [1], several objects dependent on packages
(such as derivations or grafts) are cached by the package and do not
take parameters (apart from %current-system, %current-target-system and
%graft?) into account. To fix that, my idea was to introduce an
additional parameter `%parameterized-counter', which uniquely identifies
a set of parameters and values in the <parameterized> object and which
is used as additional key by the caches.

To prevent a collision, the parameters and values are stored in a hash table,
which keeps them alive forever. Would it be preferable to use something like a
cryptographic hash instead?

For `cache!' in (guix packages), I used
`(,(scm->pointer package) . ,(%parameterized-counter)) as key together with
hash-set! and hash-ref instead of hashq-set! and hashq-ref. Is that OK?

[1] https://issues.guix.gnu.org/75879

 guix/gexp.scm     | 48 +++++++++++++++++++++++++++++++++++++++--------
 guix/packages.scm | 22 +++++++++++-----------
 tests/gexp.scm    | 31 ++++++++++++++++++++++++++++++
 3 files changed, 82 insertions(+), 19 deletions(-)

diff --git a/guix/gexp.scm b/guix/gexp.scm
index 8dd746eee0..11e3b5968f 100644
--- a/guix/gexp.scm
+++ b/guix/gexp.scm
@@ -5,6 +5,7 @@
 ;;; Copyright © 2019, 2020 Mathieu Othacehe <m.othacehe <at> gmail.com>
 ;;; Copyright © 2020 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
 ;;; Copyright © 2021, 2022 Maxime Devos <maximedevos <at> telenet.be>
+;;; Copyright © 2025 David Elsing <david.elsing <at> posteo.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -32,6 +33,7 @@ (define-module (guix gexp)
   #:use-module (srfi srfi-1)
   #:use-module (srfi srfi-9)
   #:use-module (srfi srfi-9 gnu)
+  #:use-module (srfi srfi-11)
   #:use-module (srfi srfi-26)
   #:use-module (srfi srfi-34)
   #:use-module (srfi srfi-35)
@@ -94,6 +96,7 @@ (define-module (guix gexp)
 
             with-parameters
             parameterized?
+            %parameterized-counter
 
             load-path-expression
             gexp-modules
@@ -302,7 +305,7 @@ (define* (lower-object obj
                                  (not (derivation? lowered)))
                             (loop lowered)
                             (return lowered)))
-                      obj
+                      obj (%parameterized-counter)
                       system target graft?)))))))
 
 (define* (lower+expand-object obj
@@ -321,7 +324,7 @@ (define* (lower+expand-object obj
                             (lowered (if (derivation? obj)
                                          (return obj)
                                          (mcached (lower obj system target)
-                                                  obj
+                                                  obj (%parameterized-counter)
                                                   system target graft?))))
          ;; LOWER might return something that needs to be further
          ;; lowered.
@@ -731,13 +734,40 @@ (define-syntax-rule (with-parameters ((param value) ...) body ...)
                  (lambda ()
                    body ...)))
 
+;; Counter which uniquely identifies specific parameters and values used for
+;; <parameterized>.
+(define %parameterized-counter
+  (make-parameter #f))
+
+(define %parameterized-counter-next-value 0)
+
+(define %parameterized-counters (make-hash-table))
+
+;; Add %parameterized-counter to PARAMETERS and its value,
+;; which depends on PARAMETERS and VALUES, to PARAMETER-VALUES.
+(define (add-parameterized-counter parameters parameter-values)
+  (let* ((key `(,parameters . ,parameter-values))
+         (counter
+          (match (hash-ref %parameterized-counters key)
+            (#f
+             (let ((val %parameterized-counter-next-value))
+               (hash-set! %parameterized-counters key val)
+               (set! %parameterized-counter-next-value (+ val 1))
+               val))
+            (counter counter))))
+    (values
+     (cons %parameterized-counter parameters)
+     (cons counter parameter-values))))
+
 (define-gexp-compiler compile-parameterized <parameterized>
   compiler =>
   (lambda (parameterized system target)
     (match (parameterized-bindings parameterized)
       (((parameters values) ...)
-       (let ((thunk (parameterized-thunk parameterized))
-             (values (map (lambda (thunk) (thunk)) values)))
+       (let*-values (((parameters values)
+                      (add-parameterized-counter
+                       parameters (map (lambda (thunk) (thunk)) values)))
+                     ((thunk) (parameterized-thunk parameterized)))
          ;; Install the PARAMETERS for the store monad.
          (state-with-parameters parameters values
            ;; Install the PARAMETERS for the dynamic extent of THUNK.
@@ -762,11 +792,13 @@ (define-gexp-compiler compile-parameterized <parameterized>
   expander => (lambda (parameterized lowered output)
                 (match (parameterized-bindings parameterized)
                   (((parameters values) ...)
-                   (let ((fluids (map parameter-fluid parameters))
-                         (thunk  (parameterized-thunk parameterized)))
+                   (let*-values (((parameters values)
+                                  (add-parameterized-counter
+                                   parameters (map (lambda (thunk) (thunk)) values)))
+                                 ((thunk)  (parameterized-thunk parameterized)))
                      ;; Install the PARAMETERS for the dynamic extent of THUNK.
-                     (with-fluids* fluids
-                       (map (lambda (thunk) (thunk)) values)
+                     (with-fluids* (map parameter-fluid parameters)
+                       values
                        (lambda ()
                          (match (thunk)
                            ((? struct? base)
diff --git a/guix/packages.scm b/guix/packages.scm
index 18ab23e0aa..1ee456ced2 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -11,7 +11,7 @@
 ;;; Copyright © 2022 jgart <jgart <at> dismail.de>
 ;;; Copyright © 2023 Simon Tournier <zimon.toutoune <at> gmail.com>
 ;;; Copyright © 2024 Janneke Nieuwenhuizen <janneke <at> gnu.org>
-;;; Copyright © 2024 David Elsing <david.elsing <at> posteo.net>
+;;; Copyright © 2024, 2025 David Elsing <david.elsing <at> posteo.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -57,6 +57,7 @@ (define-module (guix packages)
   #:use-module (srfi srfi-34)
   #:use-module (srfi srfi-35)
   #:use-module (srfi srfi-71)
+  #:use-module (system foreign)
   #:use-module (rnrs bytevectors)
   #:use-module (web uri)
   #:autoload   (texinfo) (texi-fragment->stexi)
@@ -1689,13 +1690,12 @@ (define (cache! cache package system thunk)
 SYSTEM."
   ;; FIXME: This memoization should be associated with the open store, because
   ;; otherwise it breaks when switching to a different store.
-  (let ((result (thunk)))
-    ;; Use `hashq-set!' instead of `hash-set!' because `hash' returns the
-    ;; same value for all structs (as of Guile 2.0.6), and because pointer
-    ;; equality is sufficient in practice.
-    (hashq-set! cache package
-                `((,system . ,result)
-                  ,@(or (hashq-ref cache package) '())))
+  (let ((result (thunk))
+        (key `(,(scm->pointer package) . ,(%parameterized-counter))))
+    (hash-set! cache key
+               `((,system . ,result)
+                 ,@(or (hash-ref cache key)
+                       '())))
     result))
 
 (define-syntax cached
@@ -1828,7 +1828,7 @@ (define (input-graft system)
                                    (with-parameters ((%current-system system))
                                      replacement))
                                   (replacement-output output))))
-                      package output system)
+                      package output (%parameterized-counter) system)
              (return #f))))
       (_
        (return #f)))))
@@ -2068,7 +2068,7 @@ (define* (package->derivation package
                                               #:system system
                                               #:guile guile)))))
                  (return drv)))
-           package system #f graft?))
+           package (%parameterized-counter) system #f graft?))
 
 (define* (package->cross-derivation package target
                                     #:optional (system (%current-system))
@@ -2091,7 +2091,7 @@ (define* (package->cross-derivation package target
                                               #:system system
                                               #:guile guile)))))
                  (return drv)))
-           package system target graft?))
+           package (%parameterized-counter) system target graft?))
 
 (define* (package-output store package
                          #:optional (output "out") (system (%current-system)))
diff --git a/tests/gexp.scm b/tests/gexp.scm
index 00bb729e76..91819806d0 100644
--- a/tests/gexp.scm
+++ b/tests/gexp.scm
@@ -1,6 +1,7 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2014-2025 Ludovic Courtès <ludo <at> gnu.org>
 ;;; Copyright © 2021-2022 Maxime Devos <maximedevos <at> telenet.be>
+;;; Copyright © 2025 David Elsing <david.elsing <at> posteo.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -487,6 +488,36 @@ (define (match-input thing)
     (return (and (eq? drv0 result0)
                  (eq? drv1 result1)))))
 
+(test-assertm "with-parameters for custom parameter"
+  (mlet* %store-monad
+      ((%param -> (make-parameter "A"))
+       (pkg -> (package
+                 (name "testp")
+                 (version "0")
+                 (source #f)
+                 (build-system trivial-build-system)
+                 (arguments
+                  (list
+                   #:builder
+                   #~(let ((port (open-file (string-append #$output) "w")))
+                       (display (string-append #$(%param) "\n") port)
+                       (close-port port))))
+                 (home-page #f)
+                 (synopsis #f)
+                 (description #f)
+                 (license #f)))
+       (obj1 -> (with-parameters ((%param "B")) pkg))
+       (obj2 -> (with-parameters ((%param "C")) pkg))
+       (result0 (package->derivation pkg))
+       (result1 (lower-object obj1))
+       (result2 (lower-object obj2))
+       (result3 (lower-object pkg)))
+    (return (and (not
+                  (or (eq? result0 result1)
+                      (eq? result0 result2)
+                      (eq? result1 result2)))
+                 (eq? result0 result3)))))
+
 (test-assert "with-parameters + file-append"
   (let* ((system (match (%current-system)
                    ("aarch64-linux" "x86_64-linux")
-- 
2.48.1

Message #8 received at 77708 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: David Elsing <david.elsing <at> posteo.net>
Cc: dev <at> jpoiret.xyz, zimon.toutoune <at> gmail.com, othacehe <at> gnu.org, ludo <at> gnu.org,
 me <at> tobias.gr, 77708 <at> debbugs.gnu.org, guix <at> cbaines.net
Subject: Re: [bug#77708] [PATCH] gexp: ‘with-parameters‘ is respected by caches.
Date: Mon, 02 Jun 2025 10:45:06 +0200

Hi David,

Apologies for the delay.

David Elsing <david.elsing <at> posteo.net> writes:

> As noted by Ludo' [1], several objects dependent on packages
> (such as derivations or grafts) are cached by the package and do not
> take parameters (apart from %current-system, %current-target-system and
> %graft?) into account. To fix that, my idea was to introduce an
> additional parameter `%parameterized-counter', which uniquely identifies
> a set of parameters and values in the <parameterized> object and which
> is used as additional key by the caches.
>
> To prevent a collision, the parameters and values are stored in a hash table,
> which keeps them alive forever. Would it be preferable to use something like a
> cryptographic hash instead?
>
> For `cache!' in (guix packages), I used
> `(,(scm->pointer package) . ,(%parameterized-counter)) as key together with
> hash-set! and hash-ref instead of hashq-set! and hashq-ref. Is that OK?
>
> [1] https://issues.guix.gnu.org/75879

Overall I have two main concerns: the added complexity and the run-time
overhead.  I would be tempted to just not pretend supporting
<parameterized> for arbitrary parameters than to pay this price.

WDYT?

> @@ -302,7 +305,7 @@ (define* (lower-object obj
>                                   (not (derivation? lowered)))
>                              (loop lowered)
>                              (return lowered)))
> -                      obj
> +                      obj (%parameterized-counter)
>                        system target graft?)))))))

[...]

> +;; Counter which uniquely identifies specific parameters and values used for
> +;; <parameterized>.
> +(define %parameterized-counter
> +  (make-parameter #f))

The “counter” really determines the dynamic scope of parameters in fact,
right?  Should it be renamed to “parameter scope” or similar?

> +(define %parameterized-counter-next-value 0)
> +
> +(define %parameterized-counters (make-hash-table))

This is very much like the regular dynamic environment (info "(guile)
Fluids and Dynamic States").

> +;; Add %parameterized-counter to PARAMETERS and its value,
> +;; which depends on PARAMETERS and VALUES, to PARAMETER-VALUES.
> +(define (add-parameterized-counter parameters parameter-values)
> +  (let* ((key `(,parameters . ,parameter-values))
> +         (counter
> +          (match (hash-ref %parameterized-counters key)

Note that this is quite expensive: hashing traverses part of KEY, and
then all of it must be traversed for comparison; in practice there would
probably be few parameters though.

> @@ -1689,13 +1690,12 @@ (define (cache! cache package system thunk)
>  SYSTEM."
>    ;; FIXME: This memoization should be associated with the open store, because
>    ;; otherwise it breaks when switching to a different store.
> -  (let ((result (thunk)))
> -    ;; Use `hashq-set!' instead of `hash-set!' because `hash' returns the
> -    ;; same value for all structs (as of Guile 2.0.6), and because pointer
> -    ;; equality is sufficient in practice.
> -    (hashq-set! cache package
> -                `((,system . ,result)
> -                  ,@(or (hashq-ref cache package) '())))
> +  (let ((result (thunk))
> +        (key `(,(scm->pointer package) . ,(%parameterized-counter))))
> +    (hash-set! cache key
> +               `((,system . ,result)
> +                 ,@(or (hash-ref cache key)
> +                       '())))

The ‘scm->pointer’ trick prevents the expensive <package> structure
traversal, but I’m unsure about the performance of switching to ‘equal?’
instead of ‘eq?’.

Does the ‘scm->pointer’ trick work with weak-key hash tables like
‘%bag-cache’?  I think it does because ‘scm->pointer’ records the link
between the pointer object and the package object in a weak hash table.
But it’s still quite bumpy.

> @@ -2068,7 +2068,7 @@ (define* (package->derivation package
>                                                #:system system
>                                                #:guile guile)))))
>                   (return drv)))
> -           package system #f graft?))
> +           package (%parameterized-counter) system #f graft?))

I wonder about the performance impact of the extra lookup key.

Thanks for working on this!

Ludo’.

Message #11 received at 77708 <at> debbugs.gnu.org (full text, mbox):

From: David Elsing <david.elsing <at> posteo.net>
To: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Cc: dev <at> jpoiret.xyz, zimon.toutoune <at> gmail.com, othacehe <at> gnu.org, ludo <at> gnu.org,
 me <at> tobias.gr, 77708 <at> debbugs.gnu.org, guix <at> cbaines.net
Subject: Re: [bug#77708] [PATCH] gexp: ‘with-parameters‘ is respected by caches.
Date: Tue, 24 Jun 2025 17:38:25 +0000

Hi Ludo',

Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:

> Apologies for the delay.

No problem, thanks for looking at the patch!

> Overall I have two main concerns: the added complexity and the run-time
> overhead.  I would be tempted to just not pretend supporting
> <parameterized> for arbitrary parameters than to pay this price.
>
> WDYT?

I think parameterized packages would be very useful. Something like the
previous approach [1] would of course be nicer, but I didn't find any
information why it was not continued. From what I can tell,
`with-parameters' is now working except for the caches, so in my opinion
it makes sense to fix that.

> The “counter” really determines the dynamic scope of parameters in fact,
> right?  Should it be renamed to “parameter scope” or similar?

I only defined it to avoid frequently recalculating the hash of the
dynamic parameters, so the caches only need to include the single
integer in the key.

>> +(define %parameterized-counter-next-value 0)
>> +
>> +(define %parameterized-counters (make-hash-table))
>
> This is very much like the regular dynamic environment (info "(guile)
> Fluids and Dynamic States").

Yes, this just assigns a unique integer to each unique set of
parameters.

>> +;; Add %parameterized-counter to PARAMETERS and its value,
>> +;; which depends on PARAMETERS and VALUES, to PARAMETER-VALUES.
>> +(define (add-parameterized-counter parameters parameter-values)
>> +  (let* ((key `(,parameters . ,parameter-values))
>> +         (counter
>> +          (match (hash-ref %parameterized-counters key)
>
> Note that this is quite expensive: hashing traverses part of KEY, and
> then all of it must be traversed for comparison; in practice there would
> probably be few parameters though.

Do you think using a cryptographic hash (to avoid collisions) would be
better? I think we need to look at the values of the parameters and not
just at object identity in case an object was modified or for objects
like strings, right?

> The ‘scm->pointer’ trick prevents the expensive <package> structure
> traversal, but I’m unsure about the performance of switching to ‘equal?’
> instead of ‘eq?’.

> I wonder about the performance impact of the extra lookup key.

I did some benchmarking with 10 runs of 'guix build --no-grafts libreoffice -d':

- Previously:
  3.684 s ± 0.019 s
- Using `scm->pointer' and `hash-set' and `hash-ref' in `cache!':
  3.712 s ± 0.027 s
- Using an additional key in `package->derivation':
  3.697 s ± 0.028 s
- With the full path applied:
  3.726 s ± 0.032 s

So there indeed seems to be a perfomance impact of the order of ~1% in
this case.

> Does the ‘scm->pointer’ trick work with weak-key hash tables like
> ‘%bag-cache’?  I think it does because ‘scm->pointer’ records the link
> between the pointer object and the package object in a weak hash table.
> But it’s still quite bumpy.

Oh that's a good point, is chaining weak hash tables a problem? I
couldn't think of another way to add the integer describing the
parameters to the key though.

Also problematic is the `%parameterized-counter' hash table, as it keeps
the keys (i.e. all parameters passed to `with-parameters') alive
forever, so I think it should also be a weak hash table, right? If the
parameters are dropped and later constructed again, the derivation would
just be recalculated, like for `%bag-cache'.

Cheers,

David

[1] https://guix.gnu.org/en/blog/2023/parameterized-packages-for-gnu-guix/

Message #14 received at 77708 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: David Elsing <david.elsing <at> posteo.net>
Cc: dev <at> jpoiret.xyz, zimon.toutoune <at> gmail.com, othacehe <at> gnu.org, ludo <at> gnu.org,
 me <at> tobias.gr, 77708 <at> debbugs.gnu.org, guix <at> cbaines.net
Subject: Re: [bug#77708] [PATCH] gexp: ‘with-parameters‘ is respected by caches.
Date: Thu, 26 Jun 2025 08:56:51 +0200

Hello,

Quick note…

David Elsing <david.elsing <at> posteo.net> writes:

> Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:

[...]

>> Overall I have two main concerns: the added complexity and the run-time
>> overhead.  I would be tempted to just not pretend supporting
>> <parameterized> for arbitrary parameters than to pay this price.
>>
>> WDYT?
>
> I think parameterized packages would be very useful. Something like the
> previous approach [1] would of course be nicer, but I didn't find any
> information why it was not continued.

Oh, I see.  The GSoC project you’re referring to was very nice but IMO
went a bit too far in terms of what it provides; but the main factor for
it being discontinued is that the intern walked away after the
internship I believe, and nobody picked it up.  FWIW, I was advocating
for something simpler and that would try to reduce the risks of
combinatorial explosion¹.

At any rate, I don’t think parameters (in the sense of SRFI-39) can be a
useful building block for parameterized packages (in the sense of Gentoo
USE flags.)  I think parameterized packages need to be implemented with
some declarative interface as was proposed during that GSoC project and
that earlier message I mentioned.

I hope that makes sense!

Thanks,
Ludo’.

¹ https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00312.html

Message #19 received at 77708-done <at> debbugs.gnu.org (full text, mbox):

From: David Elsing <david.elsing <at> posteo.net>
To: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Cc: dev <at> jpoiret.xyz, 77708-done <at> debbugs.gnu.org, zimon.toutoune <at> gmail.com,
 othacehe <at> gnu.org, ludo <at> gnu.org, me <at> tobias.gr, guix <at> cbaines.net
Subject: Re: [bug#77708] [PATCH] gexp: ‘with-parameters‘ is respected by caches.
Date: Sun, 06 Jul 2025 16:15:01 +0000

Hi,

Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:

> Oh, I see.  The GSoC project you’re referring to was very nice but IMO
> went a bit too far in terms of what it provides; but the main factor for
> it being discontinued is that the intern walked away after the
> internship I believe, and nobody picked it up.  FWIW, I was advocating
> for something simpler and that would try to reduce the risks of
> combinatorial explosion¹.

Ah ok, that makes sense. Would it be possible for multiple packages to
share the same parameter, so that it can be set for all dependencies of
a package? I guess it should be doable with `package-mapping'.
I'm also not sure the full Cartesial product of all possible parameters
should always need to be supported, as it might or some combinations
don't make sense, so I think there should be a way to specify the
supported combinations (which isn't the case for both proposals IIUC).

> At any rate, I don’t think parameters (in the sense of SRFI-39) can be a
> useful building block for parameterized packages (in the sense of Gentoo
> USE flags.)  I think parameterized packages need to be implemented with
> some declarative interface as was proposed during that GSoC project and
> that earlier message I mentioned.

Yes I agree that using SRFI-39 parameters is not very suitable for
parameterized packages. My idea was just to fix `with-parameters' until
parameterized packages are implemented properly, but it makes sense if
you don't want to support and later deprecate this.
Maybe `with-parameters' and `<parameterized>' should be renamed if they
only support `%graft?', `%current-system' and `%current-target-system'?

Thanks,
David

Message #22 received at 77708-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludovic.courtes <at> inria.fr>
To: David Elsing <david.elsing <at> posteo.net>
Cc: dev <at> jpoiret.xyz, 77708-done <at> debbugs.gnu.org, zimon.toutoune <at> gmail.com,
 othacehe <at> gnu.org, ludo <at> gnu.org, me <at> tobias.gr, guix <at> cbaines.net
Subject: Parameterized packages
Date: Fri, 11 Jul 2025 09:29:24 +0200

Hi,

David Elsing <david.elsing <at> posteo.net> writes:

> Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:
>
>> Oh, I see.  The GSoC project you’re referring to was very nice but IMO
>> went a bit too far in terms of what it provides; but the main factor for
>> it being discontinued is that the intern walked away after the
>> internship I believe, and nobody picked it up.  FWIW, I was advocating
>> for something simpler and that would try to reduce the risks of
>> combinatorial explosion¹.
>
> Ah ok, that makes sense. Would it be possible for multiple packages to
> share the same parameter, so that it can be set for all dependencies of
> a package? I guess it should be doable with `package-mapping'.
> I'm also not sure the full Cartesial product of all possible parameters
> should always need to be supported, as it might or some combinations
> don't make sense, so I think there should be a way to specify the
> supported combinations (which isn't the case for both proposals IIUC).

Yes, what I was proposing was to have both global and per-package
parameters.  Global parameters would be things like ‘x11-support?’,
whose value would be the same for all the affected packages (either all
of them are built with X11 support or none of them is).

> Yes I agree that using SRFI-39 parameters is not very suitable for
> parameterized packages. My idea was just to fix `with-parameters' until
> parameterized packages are implemented properly, but it makes sense if
> you don't want to support and later deprecate this.
> Maybe `with-parameters' and `<parameterized>' should be renamed if they
> only support `%graft?', `%current-system' and `%current-target-system'?

Yes, but I can’t think of a better name, and renaming would entail
deprecation etc.  Naming is hard.  :-)

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.