Zephyr doesn't build if x86_64 SDK toolchain isn't install

[galak]

If using the Zephyr SDK and only having one arch toolchain (for example ARM) installed on a x86-host system we get the following:

root@9b2eebb80c9e:~/zephyr/samples/hello_world/build# cmake -DBOARD=frdm_k64f ..
-- Zephyr version: 2.1.99
-- Found PythonInterp: /usr/bin/python3.6 (found suitable version "3.6.9", minimum required is "3.6") 
-- Selected BOARD frdm_k64f
-- Found west: /usr/local/bin/west (found suitable version "0.7.0", minimum required is "0.6.0")
CMake Error at /root/zephyr/cmake/compiler/gcc/generic.cmake:8 (message):
  Zephyr was unable to find the toolchain.  Is the environment misconfigured?

  User-configuration:

  ZEPHYR_TOOLCHAIN_VARIANT: zephyr

  Internal variables:

  CROSS_COMPILE: /root/zephyr-sdk/x86_64-zephyr-elf/bin/x86_64-zephyr-elf-

  TOOLCHAIN_HOME: /root/zephyr-sdk

Call Stack (most recent call first):
  /root/zephyr/cmake/generic_toolchain.cmake:70 (include)
  /root/zephyr/cmake/app/boilerplate.cmake:462 (include)
  CMakeLists.txt:5 (include)

-- Configuring incomplete, errors occurred!

[galak]

There's an assumption baked into cmake/toolchain/zephyr/0.11/generic.cmake about having the x86 toolchain installed.

[galak]

Seems like we could move setting of CROSS_COMPILETARGET${ARCH} into target.cmake, but we'd have an issue with ARM64. A few options on how we could possibly handle this -- we could move ARM64 boards into their own board/arm64 or board/aarch64 dir than early in boilerplate.cmake we could remap the setting of ARCH and have a SUB_ARCH or something that we can use to distinguish arm v aarch64.

[galak]

@carlocaione, @stephanosio @ioannisg @andrewboie @andyross @nashif @dcpleung adding you guys as a FYI to this discussion as there a bit of how do we handle architecture variants in play here. I could see xtensa & risc-v wanting something similar.

[andrewboie]

Why is it unconditionally checking for the x86_64 toolchain? It should be checking for the toolchain used to build the board, this seems like a straightforward bug and not something that requires a lot of discussion.

IOW it's not clear to me what the problem is, can you perhaps rephrase your problem statement?

[galak]

There are two files in play, generic.cmake and target.cmake

We we do cmake -DBOARD=foobar we effectively determine the 'ARCH' based on the parent dir of the board. Early on before Kconfig, we are parsing generic.cmake which is doing set(CROSS_COMPILE_TARGET x86_64-${TOOLCHAIN_VENDOR}-elf). While we can move setting of CROSS_COMPILE_TARGET to be ARCH aware, at this point of cmake parsing we only know ARCH, and so for something like aarch64 we only know we are ARM, not aarch64. Similar for xtensa, we know we are xtensa but not S1000 or intel_apl_adsp. So we need some means purely based on the board selection to know the "more specific arch".

The two ideas I have so far are either encoding something in the path or encoding something in a cmake file that the we can get to from boards///.

[andrewboie]

at first glance we might need a CONFIG_ARCH and CONFIG_SUB_ARCH or something so the toolchain to use is completely ambiguous early on 🤔

[dcpleung]

Have you looked at xtools/generic.cmake? It simply looks for any toolchain available under the directory, and could provide a quick workaround for the release.