Package: guix-patches;
Reported by: David Elsing <david.elsing <at> posteo.net>
Date: Thu, 10 Apr 2025 14:50:02 UTC
Severity: normal
Tags: patch
Done: David Elsing <david.elsing <at> posteo.net>
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.
View this report as an mbox folder, status mbox, maintainer mbox
guix <at> cbaines.net, dev <at> jpoiret.xyz, ludo <at> gnu.org, othacehe <at> gnu.org, zimon.toutoune <at> gmail.com, me <at> tobias.gr, guix-patches <at> gnu.org
:bug#77708
; Package guix-patches
.
(Thu, 10 Apr 2025 14:50:02 GMT) Full text and rfc822 format available.David Elsing <david.elsing <at> posteo.net>
:guix <at> cbaines.net, dev <at> jpoiret.xyz, ludo <at> gnu.org, othacehe <at> gnu.org, zimon.toutoune <at> gmail.com, me <at> tobias.gr, guix-patches <at> gnu.org
.
(Thu, 10 Apr 2025 14:50:02 GMT) Full text and rfc822 format available.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
guix-patches <at> gnu.org
:bug#77708
; Package guix-patches
.
(Mon, 02 Jun 2025 10:00:02 GMT) Full text and rfc822 format available.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’.
guix-patches <at> gnu.org
:bug#77708
; Package guix-patches
.
(Tue, 24 Jun 2025 17:39:02 GMT) Full text and rfc822 format available.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/
guix-patches <at> gnu.org
:bug#77708
; Package guix-patches
.
(Thu, 26 Jun 2025 06:59:02 GMT) Full text and rfc822 format available.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
David Elsing <david.elsing <at> posteo.net>
:David Elsing <david.elsing <at> posteo.net>
: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
guix-patches <at> gnu.org
:bug#77708
; Package guix-patches
.
(Fri, 11 Jul 2025 07:36:02 GMT) Full text and rfc822 format available.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’.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.