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.
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.
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?
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.