GNU bug report logs - #55248
[PATCH 0/7] gnu: Update Racket to 8.5 and Chez Scheme to 9.5.8.

Previous Next

Full log

View this message in rfc822 format

From: Philip McGrath <philip <at> philipmcgrath.com>
To: Liliana Marie Prikler <liliana.prikler <at> ist.tugraz.at>, 55248 <at> debbugs.gnu.org, Maxime Devos <maximedevos <at> telenet.be>
Subject: [bug#55248] [PATCH 1/7] gnu: racket: Update to 8.5.
Date: Sat, 7 May 2022 14:39:51 -0400

Hi,

On 5/6/22 02:37, Liliana Marie Prikler wrote:
> Hi,
> 
> Am Donnerstag, dem 05.05.2022 um 17:49 -0400 schrieb Philip McGrath:
>> Hi,
>>
>> On 5/4/22 02:53, Liliana Marie Prikler wrote:
>>> Am Dienstag, dem 03.05.2022 um 14:33 -0400 schrieb Philip McGrath:
>>>> (racket-vm-common-configure-flags): Remove incorrect comment.
>>> No.  Unless you address the issue at hand (which I don't want to be
>>> a blocker for this series, mind you), it persists.  If you don't
>>> like how the comment is written currently, you might suggest an
>>> alternative formulation, but people deserve to know that the
>>> origtree layout is a hack.
>>
>> I understand that this is your opinion. I disagree. I don't want to
>> make a big deal out of it, but I'm uncomfortable with the fact that
>> `git blame` currently attributes to me a statement of opinion which I
>> did not write and do not believe.
> Well, I'm uncomfortable with the fact that git assigns blame to people.
> The wording of the command name is (as many things in git) poorly
> chosen, but that's somewhat besides the point.  I'm leaving open the
> option of writing a comment that you're more comfortable with, but I'm
> not leaving the option of silently removing it.
> 
>> I could write a lot of prose arguing in favor of --enable-origtree as
>> a matter of opinion, but I'd rather spend my time trying to write a
>> racket-build-system, which I expect will make its usefulness more
>> obvious.
> You can argue in favour of it, but that doesn't change the fact that
> this layout breaks assumptions that are held elsewhere.  "Dump
> everything into a single directory" has never been a good deployment
> strategy, and those who use it tend to regret their decision later.
> 
>> For now, I'll limit myself to noting that, while Racket
>> supports --enable-unix-style for those who insist on it (a group
>> which formerly included me!), if you run the Racket installer script
>> [1] with default options, it will install the files that 'racket-vm-
>> cs' and similar place in "/opt/racket-vm/" in "/usr/racket".
>> Optionally, the installer will then create symlinks is "/usr/bin"
>> etc. pointing to a subset of the files that Guix's 'racket-minimal'
>> installs into'#$output'.
> This paragraph does not make as much sense to another person as you
> believe it does.  If I'm counting correctly, we're talking about three
> different configurations right now.  --enable-origtree, --enable-unix-
> style, and a default that uses neither of the two.  I don't think we
> can easily draw inferences from either to the others.
> 

Given the vehemence of your opinion, I was assuming some familiarity 
with building Racket. There are various ways of ending up with a 
"Unix-style" installation as implemented by the 
'setup/unixstyle-install' module, including `make unix-style` in the 
top-level directory, `./configure --enable-origtree=no` in the vm source 
directory, and the default answers to the installer script (which embeds 
an archive of the built files). There are some platform-specific 
details, but none that currently affect Guix. (E.g. when building for 
Mac, you can fine-tune the installation style and the use of GTK vs. 
Cocoa for `racket/gui`).

An in-place installation (as produced by --enable-origtree) is 
self-contained and can be freely relocated. A Unix-style installation 
moves parts of an in-place build to better suit a shared FHS prefix 
(e.g. "etc/config.rktd" -> "etc/racket/config.rktd"; "collects" -> 
"share/racket/collects"), injects absolute paths to find parts of 
itself, and generates an uninstall script. But those things are not 
useful in this context: the `racket` executable from the VM packages 
should only be run to build the rest of Racket, and we want to build a 
Racket installation additive, not by mutating it.

>> To the extent that there is an assertion of fact embedded in:
>>
>>>> -      ;; XXX: origtree layout is required by some other packages
>>>> down the
>>>> -      ;; bootstrap chain.  Remove these flags as soon as we can
>>>> do without them.
>>
>> it is not true. The packages which operate on a Racket installation
>> with this layout (e.g. 'distro-build' and 'raco-cross') are not part
>> of "the bootstrap chain", and the packages which are part of the
>> bootstrap chain do not require --enable-origtree, except to the
>> extent that e.g. it is a convenient way of telling apart multiple
>> executables named "racket".
>  From my POV "the bootstrap chain" consists of everything from the first
> VM to the final racket package.  In that sense, I am sure you
> communicated elsewhere that it is very important to get layers going,
> and I'm also fairly certain that we can't currently build the VM chain
> without origtree either -- at least it would require nontrivial
> modification of said packages.
> 

It is true that removing `--enable-origtree` would require nontrivial 
changes, primarily to `configure-layer.rkt`.

> Again, if you have a formulation that is more factual, but doesn't span
> several pages like other comments in racket.scm do, you are free to
> replace it.

I will try to write a strictly factual comment.

> However, for the sake of a racket-build-system even, I
> suggest that it would be better if racket's own layout was meaningful.
> In other words, why can't racket be more like guile and support
> RACKET_LOAD_PATH and RACKET_LOAD_COMPILED_PATH?
> 

I mean, you are certainly free to dislike Racket's model of linking and 
compilation! And, in fact, Racket has enough configuration options and 
compatibility hooks that you could try to use it with e.g. PLTCOLLECTS, 
though it would not be recommended, well-tested, or useful for most 
Racketeers.

With the caveat that all analogies are imprecise, why does Guix prefer 
to avoid relying on LD_LIBRARY_PATH for C libraries? From my 
perspective, Racket avoids at least several (maybe not all, but we shall 
see) of the weaknesses/restrictions described in [1]:

> This is not the end of stat storms, though. Interpreters and language
> run-time systems rely on search paths—GUILE_LOAD_PATH for Guile,
> PYTHONPATH for Python, OCAMLPATH for OCaml, etc.—and are equally prone
> to stormy application startups. Unlike ELF, they do not have a mechanism
> akin to RUNPATH, let alone a run-time search path cache. We have yet to
> find ways to address these.

-Philip

[1]: 
https://guix.gnu.org/en/blog/2021/taming-the-stat-storm-with-a-loader-cache/

Previous Next

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