Bug: build_binder.sh: fails in OE ARM cross-compile environment due to hardcoded BUILD_HOST_AIDL=ON and missing OECORE env suppression

[Anbukannadhasan]

Problem/Opportunity

build_binder.sh has two compounding failures when invoked from an OpenEmbedded (OE) ARM cross-compile environment:

Problem 1 - BUILD_HOST_AIDL=ON is hardcoded regardless of active compiler Lines 250 and 257 of build_binder.sh unconditionally pass -DBUILD_HOST_AIDL=ON to cmake. When CC/CXX are set to an ARM cross-compiler (as OE does), cmake compiles the AIDL host tool binary using the ARM cross-compiler. This fails in two ways:

• The resulting binary is ARM - it cannot execute on the x86 build host. cmake fails immediately when it tries to run the AIDL tool to verify it.
• Even when trying with an x86 compiler, the OE native sysroot prepends its own m4 to PATH. That older m4 rejects the --gnu flag that bison passes when building the AIDL parser grammar, producing a cryptic m4 error mid-build that has nothing to do with user code.

Problem 2 - OECORE_* env vars are not suppressed before cmake configure linux_binder_idl/CMakeLists.txt line 174 auto-enables BUILD_ENV_YOCTO=ON whenever OECORE_NATIVE_SYSROOT or OECORE_TARGET_SYSROOT are present in the environment. When BUILD_ENV_YOCTO=ON, all cmake install() rules are disabled, so no libraries or headers are ever installed to out/target/. build_binder.sh does not unset these variables before running cmake configure, so calling it inside an active OE shell results in a build that appears to succeed but produces no output.

Steps to reproduce

1. Source an OE ARM toolchain environment (sets CC, CXX, CFLAGS, OECORE_NATIVE_SYSROOT, OECORE_TARGET_SYSROOT)
   sc docker run rdk-kirkstone /bin/bash
   source /opt/toolchains/rdk-glibc-x86_64-arm-toolchain/environment-setup-armv7vet2hf-neon-oe-linux-gnueabi
2. cd rdk-halif-aidl
3. ./build_binder.sh

Expected Behavior

• When CC points to an ARM cross-compiler, build_binder.sh detects this and passes -DBUILD_HOST_AIDL=OFF so only the binder runtime libraries are built (skipping the AIDL host tool, which requires an x86 compiler)
• Before running cmake configure, OECORE_NATIVE_SYSROOT and OECORE_TARGET_SYSROOT are temporarily unset so linux_binder_idl/CMakeLists.txt does not auto-enable BUILD_ENV_YOCTO, and cmake install() rules execute normally - libraries and headers land in out/target/
• After cmake configure completes, the OECORE vars are restored

Actual Behavior

• cmake fails either attempting to execute an ARM binary on x86, or mid-build with a m4: unrecognized option '--gnu' error from the OE-injected m4
• Even if the build completes, out/target/ is empty because BUILD_ENV_YOCTO=ON skipped all install() rules

Notes (Optional)

[Ulrond]

Reviewed and verified both reported symptoms — thanks for the detailed write-up. Both are real, but they stem from running the developer wrapper scripts in an environment they're not designed for, rather than from a defect in the build itself:

• Host AIDL tool built for ARM — the AIDL compiler is a host tool used offline by the architecture team to generate C++, which is then committed. Target/Yocto builds consume the committed C++ and never need it (README: "production build needs no Python or AIDL toolchain"). It should always be built with the host compiler, never the cross compiler.
• OECORE_* → BUILD_ENV_YOCTO=ON disables installs — this is correct behaviour for a production build invoked directly through CMake.

The contract is already documented (BUILD.md: "Production build systems (Yocto/BitBake) MUST call CMake directly … the wrapper scripts are NOT suitable for production recipes", and the recipe example passes -DBUILD_HOST_AIDL=OFF). A Yocto/cross build using the direct-CMake path has neither symptom.

Fix in #628:

• A shared dev_env_guard.sh makes the wrapper scripts fail fast with a clear pointer when a cross CC or OECORE_*_SYSROOT is detected, instead of silently producing broken/empty output. (clean/help still work anywhere; BINDER_ALLOW_CROSS_ENV=1 overrides.)
• New docs/standards/build_integration.md documents the third-party/Yocto integration contract (direct CMake, required variables, recipe pattern), linked from the README.

[Ulrond]

Both symptoms reproduce exactly as reported, and both are correct behaviour for a production build invoked directly through CMake: the host AIDL tool is an offline architecture-team tool (production consumes committed C++ with -DBUILD_HOST_AIDL=OFF), and BUILD_ENV_YOCTO auto-enabling from OECORE_* deliberately defers staging to BitBake.

The only real defect was that the developer wrapper scripts failed silently in a cross/OE shell (empty out/target/). #628 fixes that with dev_env_guard.sh — the wrappers now fail fast when OECORE_*_SYSROOT or a cross CC is detected (overridable via BINDER_ALLOW_CROSS_ENV=1) — plus a new docs/standards/build_integration.md documenting the direct-CMake/Yocto integration contract.

Closing as resolved by #628. Production/Yocto integration uses direct CMake and was never affected.