add a custom toolchain for customized use

[FaqiangZhu-nxp]

A custom toolchain is added which can use below build argument to specify the compiler and archive tools to be used when compile the code:

• target_cc
• target_cxx
• target_ar

To use this toolchain as default toolchain, use the build argument "custom_toolchain" to specify it.

Cross-compile can work with this toolchain, for example, build the code on x64 host for aarch64 running Linux.
This toolchain is tested to build code for NXP i.MX 8MM EVK board running a yocto release with the yocto SDK, the command to generate ninja files can be:

    PKG_CONFIG_SYSROOT_DIR=<sdk_root_dir> \
    PKG_CONFIG_LIBDIR=${PKG_CONFIG_SYSROOT_DIR}/usr/lib/pkgconfig:${PKG_CONFIG_SYSROOT_DIR}/usr/share/pkgconfig \
    gn gen out/aarch64 --args='target_os="linux" target_cpu="arm64" arm_arch="armv8-a"
        import("//build_overrides/build.gni")
        target_cflags=[ "--sysroot=<sdk_root_dir>" ]
        target_ldflags=[ "--sysroot=<sdk_root_dir>" ]
        custom_toolchain="${build_root}/toolchain/custom"
        target_cc="<gcc_in_sdk>"
        target_cxx="<g++_in_sdk>"
        target_ar="<ar_in_sdk>"'

Problem

it does not try to fix any problem.

Change overview

added a custom toolchain.

Testing

• If manually tested, what platforms controller and device platforms were manually tested, and how?
  With this change and the right command to use NXP yocto release SDK based on Linux 5.10 kernel, try to build below target:
  "//examples/lighting-app/linux:chip-lighting-app"
  "//examples/chip-tool"
  Then the build out binary can be executed on NXP i.MX 8MM (Arm Cortex A53) EVK board running the corresponding yocto release image,

[CLAassistant]

All committers have signed the CLA.

[mspang]

I understand <target-triple>-<tool> is a common tool naming convention for gcc & binutils but I don't think it is necessarily a good idea to assume it. Could you make separate arguments for each tool instead?

E.g.

# build/toolchain/custom/BUILD.gn ?

import("//build_overrides/build.gni")
import("${build_root}/toolchain/gcc_toolchain.gni")
import("${build_root}/config/compiler/compiler.gni")

declare_args() {
  # C compiler executable to use for target build.
  target_cc = ""

  # C++ compiler to use for target build.
  target_cxx = ""

  # Archive tool to use for target build.
  target_ar = ""
}

gcc_toolchain("target") {
  ar = target_ar
  cc = target_cc
  cxx = target_cxx

  toolchain_args = {
    current_os = target_os
    current_cpu = target_cpu
    is_clang = is_clang
  }
}

Also, could you maybe just check that definition into the repository somewhere and point custom_toolchain at it to use it?

  gn gen out/custom --args="
    custom_toolchain=\"//build/toolchain/custom:target\"
    target_cc = \"${CROSS_COMPILE}-gcc\"
    target_cxx = \"${CROSS_COMPILE}-g++\"
    target_cxx = \"${CROSS_COMPILE}-ar\"
  "

The current modifications to BUILDCONFIG.gn activate for any Linux ARM config even if you are running on a Linux ARM host and you are not cross compiling, so your compiler is really just "gcc".

[FaqiangZhu-nxp]

Hi @mspang
it's a good idea to make separate arguments for each tool.

For your second comment, in fact, I used to specify the toolchain with build argument "custom_toolchain", and then found it a bit unease of use:

1. when I use gn at the top direcory of connectedhomeip, I specify the custom toolchain like: custom_toolchain="//build/toolchain/linux_arm:linux_arm"
2. when I use gn at a subdirectory like "examples/lighting-app/linux/", I specify the custom toolchain like: custom_toolchain="//third_party/connectedhomeip/build/toolchain/linux_arm:linux_arm"

Different string is used to specify the same toolchain, For me this is totally okay, but I think that this may be a bit confusing for customers who are beginners of gn tools. Can I made the change to "build/config/BUILDCONFIG.gn" like below?
else if (target_os == "linux" && (target_cpu == "arm64" || target_cpu == "arm") && target_cpu != host_cpu) { _default_toolchain = "${_build_overrides.build_root}/toolchain/linux_arm" }

[mspang]

Hi @mspang
it's a good idea to make separate arguments for each tool.

For your second comment, in fact, I used to specify the toolchain with build argument "custom_toolchain", and then found it a bit unease of use:

1. when I use gn at the top direcory of connectedhomeip, I specify the custom toolchain like: custom_toolchain="//build/toolchain/linux_arm:linux_arm"
2. when I use gn at a subdirectory like "examples/lighting-app/linux/", I specify the custom toolchain like: custom_toolchain="//third_party/connectedhomeip/build/toolchain/linux_arm:linux_arm"

Different string is used to specify the same toolchain, For me this is totally okay, but I think that this may be a bit confusing for customers who are beginners of gn tools.

What about

gn gen out/custom --args="
    import(\"//build_overrides/build.gni\")
    custom_toolchain=\"${build_root}/toolchain/linux_arm:linux_arm\"
    target_cc = \"${CROSS_COMPILE}-gcc\"
    target_cxx = \"${CROSS_COMPILE}-g++\"
    target_cxx = \"${CROSS_COMPILE}-ar\"
"

Otherwise I think defining a new argument and doing something like

gn gen out/custom --args="
    use_custom_target_toolchain = true
    target_cc = \"${CROSS_COMPILE}-gcc\"
    target_cxx = \"${CROSS_COMPILE}-g++\"
    target_cxx = \"${CROSS_COMPILE}-ar\"
"

would be fine.

Can I made the change to "build/config/BUILDCONFIG.gn" like below?
else if (target_os == "linux" && (target_cpu == "arm64" || target_cpu == "arm") && target_cpu != host_cpu) { _default_toolchain = "${_build_overrides.build_root}/toolchain/linux_arm" }

I don't think we should couple providing a toolchain to cross compiling on Linux. Linux ARM[64] is a very common target, and we already need to support it well for Raspberry Pi. This should be made to work by using the compiler that running the "bootstrap" process provides you:

gn gen out/arm --args='target_cpu="arm" is_clang=true'

[FaqiangZhu-nxp]

Thank you, @mspang , I've updated the PR based on your comments.

[mspang]

There is nothing ARM specific about this. I think you are looking for just a customizable toolchain.