Chez for architectures without native backends

[LiberalArtist]

@mflatt

Maybe that check should move before the preceding block that sets MACH, an then add check here that "${MACH}" = ""?

I thought this seemed right, but, when I started looking at changing the code, I was less sure. If the check I pointed to:

@LiberalArtist

# For a pb build where Racket is supplied, force cross-build
# mode on the assumption that the host is not a pb build
# (because it should be created with default configure options)
if test "${enable_pb}" = "yes" ; then
  if test "${enable_racket}" != "" ; then
    if test "${enable_target}" = "" ; then
      enable_target="${MACH}"
    fi
  fi
fi

moved before the preceding block beginning with if test "${enable_mach}" != "", I think the result would be the same, because the preceding case "$MACH_HOST_CPU" statement sets MACH="" for powerpc64*, and the value from --enable-mach=tpb64l won't have been consulted yet.

---

Tangentially, I think:

  powerpc64*)
    MACH=""
    pb_machine_name="${thread_prefix}pb64b"
    # MACH="${thread_prefix}ppc64${MACH_OS}"
    ;;

is wrong. POWER8 and POWER9 chips can be run in either big-endian or little-endian mode: config.sub normalizes them as e.g. powerpc64-unknown-linux-gnu and powerpc64le-unknown-linux-gnu. IIUC, this is set in the firmware or something: a given operating system runs in big-endian or little-endian mode, not both, so Debian has ports for both ppc64 (big-endian) and ppc64el (little-endian). (Guix only supports little-endian mode.)

More generally, I think it would be better to use the standard Autoconf macros AC_C_BIGENDIAN and AC_CHECK_SIZEOF rather than having to explicitly recognize architecture and os names.

---

As I looked around more, it seems there's a related assumption in this block slightly later in the file:

if test "${enable_racket}" != "" ; then
  if test "${enable_racket}" != "auto" ; then
    SETUP_BOOT_MODE=--chain
  fi
  # In non-cross mode, we interpret `--enable-racket` to supply a
  # Racket used only for generating Chez Scheme boot files
  if test "${CROSS_MODE}" = "cross" ; then
    RACKET="${enable_racket}"
  elif test "${enable_racket}" != "auto" ; then
    BOOTFILE_RACKET="${enable_racket}"
  fi
fi

Until now, Guix has been configureing our racket-vm-cs package with both --enable-racket and --enable-scheme. The intention was that the provided scheme would be used to generate the bootfiles and racket (CS when cross-compiling, 3M otherwise) would be used for other purposes: in particular, because Guix policy takes an especially firm stance on bootstrapping, we want to be able to schemify the regexp, io, and thread layers. However, it seems we were not actually doing that yet, so, as I workaround, I tried not providing --enable-racket for non-cross builds: it didn't break existing builds, and I've asked Thiago to try it on hardware.

For a different approach, could we just delete this block?

@LiberalArtist

# For a pb build where Racket is supplied, force cross-build
# mode on the assumption that the host is not a pb build
# (because it should be created with default configure options)
if test "${enable_pb}" = "yes" ; then
  if test "${enable_racket}" != "" ; then
    if test "${enable_target}" = "" ; then
      enable_target="${MACH}"
    fi
  fi
fi

If I'm following correctly, it seems like it's meant to handle a "cross" build for the current system, but for a pb or pbarch machine type: is there another way to handle that case?