[PATCH] D126313: [CMake] Don't pass CMAKE_C(XX)_COMPILER to the nested NATIVE build

Fri May 27 14:43:53 PDT 2022

phosek added a comment.

In D126313#3543240 <https://reviews.llvm.org/D126313#3543240>, @mstorsjo wrote:

> In D126313#3543213 <https://reviews.llvm.org/D126313#3543213>, @phosek wrote:
>
>> I looked at the change and read your description but still don't understand the motivation, Can you explain why is using `CMAKE_C(XX)_COMPILER` a problem
>
> When I cross compile LLVM on linux, targeting Windows, I configure that build with e.g. `-DCMAKE_CROSSCOMPILING=TRUE -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_C_COMPILER=x86_64-w64-mingw32-clang -DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-clang++`. Now this cross build will try to build native tblgen executables with `x86_64-w64-mingw32-clang++`, which obviously isn't going to work.
>
>> and how do we know that the default that's picked up by CMake will be the correct one?
>
> The assumption is that if you run CMake without `CMAKE_CROSSCOMPILING` and without specifying `CMAKE_CXX_COMPILER` (which it will do for the nested native build), it will pick the system's default compiler (`cc` and `c++` on unix, or MSVC and/or gcc on windows, etc) which is supposed to produce executables that can run on the build host.

Thanks for clarification, that helps and I understand the motivation now.

Not passing through `CMAKE_C(XX)_COMPILER` to the sub-build makes sense, but not setting `CMAKE_C(XX)_COMPILER` may be a problem. For example, our bots there's no host compiler (intentionally), we fetch the host compiler before the configuration step and pass it explicitly via `CMAKE_C(XX)_COMPILER` so in our case, with this change the sub-build would fail to find a compiler. We might need another way to set the compiler for the sub-build.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D126313/new/

https://reviews.llvm.org/D126313