[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2.
[bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2.
Sun, 25 Jul 2021 04:22:03 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
On 7/20/21 5:40 AM, Leo Prikler wrote:
Am Montag, den 19.07.2021, 17:46 -0400 schrieb Philip McGrath:
As you'd probably guess, `lib-search-dirs` and other `-search-dirs`
"config.rktd" entries specify search paths. The `#f` value is used
specify the point at which the default search path should be spliced
into the list: a configuration file can ignore the default altogether
exercise fine-grained control over the search order. Using `#f` also
helps to maintain something closer to a single point of control,
than hard-code the same string constants in several places.
Okay, but for this specific config, we could still splice #f ourselves
(particularly to also get full store paths), or can we not thanks to
the non-constant nature of #f?
Most importantly, the default value is not always a constant: for
example, command-line flags and Racket parameters control whether
user-specific paths are included.
How exactly would this play out? Would for example one version of #f
contain all of the user-installed packages in ~/.guix-profile whereas
the other would only contain racket's own path?
(For `lib-search-dirs` in particular, it's also worth noting that
these are Racket-specific search directories: it does not control the
use of OS-level defaults for e.g. `dlopen`.)
Perhaps a confusing naming scheme, but okay.
The short answer is that I don't think including #f is causing any
problems, whereas trying not to include it seems likely to cause a
variety of problems.
I'll try to explain more clearly.
It might be more useful to look at the second patch in the series, which
uses the "extend-layer.rkt" script to generate a "config.rkt" file for
the `racket` package, and especially the third patch, which replaces
this code completely for the `racket-minimal` package:
On 7/19/21 2:31 AM, Philip McGrath wrote:
+ (add-before 'configure 'initialize-config.rktd
(lambda* (#:key inputs #:allow-other-keys)
- (chdir "src")
+ (define (write-racket-hash alist)
+ ;; inside must use dotted pair notation
+ (display "#hash(")
+ (for-each (match-lambda
+ ((k . v)
+ (format #t "(~s . ~s)" k v)))
+ (display ")\n"))
+ (mkdir-p "racket/etc")
+ (with-output-to-file "racket/etc/config.rktd"
+ (lambda ()
+ . (#f ,@(map (lambda (lib)
+ (string-append (assoc-ref inputs
+ . (,(string-append
This code creates a template "config.rktd" file used in the build
process: the distributed source tarballs contain such a template
already, which is why we didn't need explicitly configure `catalogs` to
add the release-pinned package catalog until this change. It is added
before the `#f` so that the release catalog is checked before the
default catalogs (which point to the latest sources). For
`lib-search-dirs`, on the other hand, we want Racket-specific library
paths to be tried first, and indeed for layers of a Racket installation
to be searched in order, so `#f` is at the head of the list.
The Racket build process extends the template "config.rktd" file based
on build options like the `--prefix` passed to `configure`. For example,
it configures `lib-dir` to "lib/racket" within the store output
directory. (It would be incorrect to set those values in the template
"config.rktd" file because it is used in the build process before
The `#f` entry in `lib-search-dirs` is usually replaced by a
user-specific path like "/home/philip/.local/share/racket/8.1/lib" and
the installation-wide path specified by the `lib-dir` key, unless one or
both are changed. Omitting the `#f` entry means that neither of paths
are ever included. I don't know of any real-life circumstance in which
one would want such a "config.rktd" file. In particular, missing `#f`
entries creates problems for layered installations, which use these
search paths to find earlier layers.
There are some other configuration possibilities we may want to explore
as Guix's support for Racket packages improves, such as "addon"
tethering and customizing the "installation name" or "build stamp".
However, this patch series does not attempt to change how Guix's Racket
packages work, other than correcting the error I introduced in
<https://issues.guix.gnu.org/47180>. Racket installed via Guix has the
same behavior in this respect as Racket installed via Debian or other
package managers, and that's a way of using Racket I think Guix will
want to continue to support.
[bug#49280] [PATCH v2 0/3] gnu: racket: Update to 8.2. Bootstrap from C., Ludovic Courtès, 2021/07/30
[bug#49280] References to unversioned source tarballs, Ludovic Courtès, 2021/07/30
- [bug#49280] [PATCH 0/4] gnu: racket: Add racket-next. Bootstrap from C., Ludovic Courtès, 2021/07/08
- [bug#49280] [PATCH 0/4] gnu: racket: Add racket-next. Bootstrap from C., Philip McGrath, 2021/07/18
- [bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2., Leo Prikler, 2021/07/19
- [bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2., Philip McGrath, 2021/07/19
- [bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2., Leo Prikler, 2021/07/20
- [bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2.,
Philip McGrath <=
- [bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2., Leo Prikler, 2021/07/25
- [bug#49280] [PATCH v2 1/3] gnu: racket: Update to 8.2., Philip McGrath, 2021/07/25
- bug#49280: [PATCH v2 0/3] gnu: racket: Update to 8.2. Bootstrap from C., Ludovic Courtès, 2021/07/30