[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#57050] [PATCH v2 08/13] gnu: racket: Support cross-compiling the VM

From: Philip McGrath
Subject: [bug#57050] [PATCH v2 08/13] gnu: racket: Support cross-compiling the VM packages.
Date: Thu, 11 Aug 2022 19:23:15 -0400
User-agent: Cyrus-JMAP/3.7.0-alpha0-811-gb808317eab-fm-20220801.001-gb808317e


On Thu, Aug 11, 2022, at 7:58 AM, Liliana Marie Prikler wrote:
> Am Donnerstag, dem 11.08.2022 um 07:08 -0400 schrieb Philip McGrath:
>> Cross-compilation works for 'racket-vm-cgc', 'racket-vm-bc', and
>> 'racket-vm-cs'. These changes are not enough to cross-compile
>> 'racket-minimal' or 'racket': that would require building and loading
>> cross-compilation pluggins for 'racket-vm-cs', which will be much
> plugins
>> easier once we can build the package 'raco-cross'.
>> * gnu/packages/racket.scm (racket-vm-cgc): Add 'this-package' when
>> cross-compiling.
>> (racket-vm-bc)[native-inputs]: Adjust accordingly.
>> (racket-vm-cs)[native-inputs]: Use 'racket-vm-cs' instead of
>> 'racket-vm-bc' when cross-compiling. Adapt to changes to
>> 'racket-vm-cgc'.
> Is that needed?  Can racket-vm-cs not be "cross-bootstrapped"?

I'm not sure what "cross-bootstrapped" means.

Chez Scheme is more like GCC than LLVM in that it only generates code for one 
target at a time. Unlike GCC, you don't have a separate executable for each 
backend: the C part and the pure Scheme part can be shared. For 
cross-compilation, you generate an "xpatch" file, a compiler plugin somewhat 
like a bootfile, for the target machine type. You use it by loading it into a 
running `scheme` process: AIUI it, as a side-effect, mutates parts of the 
compiler to turn it into a compiler for the target architecture. Once an 
"xpatch" is loaded, some parts of the host functionality are no longer 
accessible. Racket provides a somewhat more convenient interface, including the 
ability to run a copy of itself in a subprocess to drive the compilation. In 
keeping with Racket's overall design, the VM layer provides only primitive 
hooks, leaving it up to packages to provide higher-level interfaces that deal 
with managing native- and cross-compiled files in parallel, dependency 
management, and other issues.

The shorter version is that I asked Matthew Flatt how he recommended managing 
cross-compilation, and he strongly suggested first getting non-cross package 
builds working well, then reusing as much of `raco cross` as possible.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]