toolchain.compiler is discarded unless it names a predefined toolchain: clang builds with gcc, and a cross config emits a host binary

[Kartikey1306]

resolve_toolchain() (ebuild/build/toolchain.py:77-85) uses toolchain.compiler only as a key into PREDEFINED_TOOLCHAINS, then builds every tool name as f"{prefix}gcc":

predef = PREDEFINED_TOOLCHAINS.get(compiler, {})
if not prefix and predef.get("prefix"):
    prefix = predef["prefix"]
...
return ResolvedToolchain(cc=f"{prefix}gcc", cxx=f"{prefix}g++", ar=f"{prefix}ar", ...)

Any value that is not one of the five toolchain names yields predef = {}, prefix = "" and cc = "gcc" — with no warning and no validation. So:

• compiler: clang builds with gcc.
• compiler: cc builds with gcc.
• compiler: arm-none-eabi-gcc builds a host binary and reports success.

Reproduced

build.yaml:

toolchain:
  compiler: arm-none-eabi-gcc
  arch: arm
targets:
  - name: fw
    type: executable
    sources: [src/main.c]

$ ebuild build
[ok] Build completed successfully.
[info]   OK   toolchain            gcc
[info] Ready to flash.

$ grep '^cc = ' _build/build.ninja
cc = gcc

$ file _build/fw
_build/fw: Mach-O 64-bit executable arm64      <- host binary, not ARM firmware

The flash/RAM footprint is then measured with the host size as well (ebuild/build/footprint.py:108-115), so the reported numbers describe the wrong architecture.

Note on the documented spelling

docs/task_cortex_r5_example.md:31-34 spells a cross build as compiler: gcc with prefix: arm-none-eabi-, and that works today. The failure is for the other spellings, which the field name invites and which fail silently rather than loudly.