[bug#55248] [PATCH 6/7] gnu: stex: Get machine type dynamically.

[Philip McGrath <philip@philipmcgrath.com>]

Hi,

On 5/4/22 02:58, Liliana Marie Prikler wrote:
> Am Dienstag, dem 03.05.2022 um 14:33 -0400 schrieb Philip McGrath:
>> * gnu/packages/chez.scm (stex)[arguments]: Run 'scheme' to determine
>> the machine type.
> How is this beneficial?  

At some high level of generality, there are two ways we could determine 
the machine type:*

   1. We could predict ahead of time what it will be; or
   2. We can ask the `scheme` executable we actually have.

Trying to predict is easy to get wrong, because there's more than one 
possible machine type for a given system: currently that's true due to 
"--threads", and it will be even more true with "portable bytecode" 
back-ends.

The `scheme` executable we're compiling with knows the definitive answer.

This lets us remove the only use of 'nix-system->chez-machine'.

> What about cross-compilation?

I remembered this backwards; it should be `(#%$target-machine)` rather 
than `(machine-type)`. I'll fix that. But note that upstream stex does 
not support cross-compilation (though I hope to fix that one day). For 
example, both `Makefile` and `Mf-stex` contain:

     m := $(shell echo '(machine-type)' | $(Scheme) -q)

(* To some extent there's an XY problem here: we don't care about the 
machine type per se, we care about the extension of intermediate object 
files we don't want to have installed, analogous to ".o" files. I think 
[1] upstream may have incidentally fixed the issues that made us build 
in that odd way, but it hasn't been part of a release yet. I plan to 
reevaluate before Racket 8.6, when we'll need [2] anyway to fix a bug 
exposed by Zuo.)

-Philip

[1]: https://github.com/dybvig/stex/pull/5
[2]: https://github.com/dybvig/stex/pull/6