GNU bug report logs - #49280
[PATCH v2 0/3] gnu: racket: Update to 8.2. Bootstrap from C.

Previous Next

Full log

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

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Leo Prikler <leo.prikler <at> student.tugraz.at>, 49280 <at> debbugs.gnu.org
Subject: Re: [PATCH v2 1/3] gnu: racket: Update to 8.2.
Date: Sun, 25 Jul 2021 04:22:03 -0400

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
>> to
>> specify the point at which the default search path should be spliced
>> into the list: a configuration file can ignore the default altogether
>> or
>> exercise fine-grained control over the search order. Using `#f` also
>> helps to maintain something closer to a single point of control,
>> rather
>> 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)))
> +                         alist)
> +               (display ")\n"))
> +             (mkdir-p "racket/etc")
> +             (with-output-to-file "racket/etc/config.rktd"
> +               (lambda ()
> +                 (write-racket-hash
> +                  `((lib-search-dirs
> +                     . (#f ,@(map (lambda (lib)
> +                                    (string-append (assoc-ref inputs 
lib)
> +                                                   "/lib"))
> +                                  '("openssl"
> +                                    "sqlite"))))
> +                    (catalogs
> +                     . (,(string-append
> +                          "https://download.racket-lang.org/releases/"
> +                          ,version
> +                          "/catalog/")
> +                        #f))))))
>                #t))

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

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.

-Philip

Previous Next

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