Respect CMAKE_<LANG>_COMPILE_OPTIONS_TARGET

[mvf]

In cross builds with CMAKE_<C|CXX>_COMPILER_TARGET, a hard-coded --target= was passed to the compiler during linking. Some compilers, such as QNX's QCC wrapper, use a different parameter and the build would fail.

To fix this, take the parameter name from CMake's CMAKE_<LANG>_COMPILE_OPTIONS_TARGET, with a fallback to --target=.

The variable was added to CMake back in 2013 with the very change that added CMAKE_<LANG>_COMPILER_TARGET: Kitware/CMake@76552d5. Nowadays, many cross compilers declare this variable:

$ grep -r '_COMPILE_OPTIONS_TARGET ' cmake
cmake/Modules/CMakeSwiftInformation.cmake:44:set(CMAKE_Swift_COMPILE_OPTIONS_TARGET "-target ")
cmake/Modules/Compiler/Clang.cmake:39:      set(CMAKE_${lang}_COMPILE_OPTIONS_TARGET "-target ")
cmake/Modules/Compiler/Clang.cmake:42:      set(CMAKE_${lang}_COMPILE_OPTIONS_TARGET "--target=")
cmake/Modules/Compiler/IBMClang.cmake:33:  set(CMAKE_${lang}_COMPILE_OPTIONS_TARGET "--target=")
cmake/Modules/Compiler/IntelLLVM.cmake:83:    set(CMAKE_${lang}_COMPILE_OPTIONS_TARGET "--target=")
cmake/Modules/Compiler/LLVMFlang-Fortran.cmake:16:set(CMAKE_Fortran_COMPILE_OPTIONS_TARGET "--target=")
cmake/Modules/Compiler/QCC.cmake:11:  set(CMAKE_${lang}_COMPILE_OPTIONS_TARGET "-V")
cmake/Modules/Platform/Windows-Clang.cmake:266:    set(CMAKE_${lang}_COMPILE_OPTIONS_TARGET "-target ")
cmake/Modules/Platform/Windows-Clang.cmake:268:    set(CMAKE_${lang}_COMPILE_OPTIONS_TARGET "--target="

[jschwe]

are there any cases where CMAKE_<LANG>_COMPILE_OPTIONS_TARGET contains a comma?

[mvf]

No, but if there ever was one, the CMake error would be pretty cryptic. 😅

Learned this the hard way in another change I got lined up, which gives the same treatment to --sysroot. There, the QCC parameter is -Wc,-isysroot,.

It's probably fine to skip the escaping here though, if you prefer.

[jschwe]

another change I got lined up, which gives the same treatment to --sysroot

In that case, could you perhaps follow-up in the upstream CMake issue https://gitlab.kitware.com/cmake/cmake/-/issues/21382#note_852685 and clarify if CMake can officially document these two variables? Brad king seems to have indicated this is fine in the linked comment, but it would be good to have some confirmation, and even better if we could merge a PR to CMake first which documents these variables (to make them part of the official API)

It's probably fine to skip the escaping here though, if you prefer.

I would prefer skipping it unless necessary.

[mvf]

Nice find, I'll approach upstream to get these documented.

[jschwe]

@mvf Did you receive any feedback from the CMake Maintainers?