CMAKE_MAKE_PROGRAM Issues

[trampas]

I am pretty sure this is not a vscode-make-tools issue, but maybe someone has seen this before?

In my CMakeLists.txt I set the CMAKE_MAKE_PROGRAM to the specific version of ninja I want to use (which is same ninja version as in my path at the moment).

set(CMAKE_MAKE_PROGRAM “${CMAKE_SOURCE_DIR}/xpacks/@xpack-dev-tools/ninja-build/.content/bin/ninja.exe”)

I also have this set.
set(CMAKE_TRY_COMPILE_TARGET_TYPE “STATIC_LIBRARY”)

However when I do this the compiler test fails:

Compiling the C compiler identification source file “CMakeCCompilerId.c” failed.
Compiler: D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/arm-none-eabi-gcc.exe
Build flags:
Id flags:

The output was:
1

  D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/lib\\libc.a(libc_a-exit.o): in function `exit':
  exit.c:(.text.exit+0x28): undefined reference to `_exit'
  D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/lib\\libc.a(libc_a-closer.o): in function `_close_r':
  closer.c:(.text._close_r+0x18): undefined reference to `_close'
  D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/lib\\libc.a(libc_a-lseekr.o): in function `_lseek_r':
  lseekr.c:(.text._lseek_r+0x24): undefined reference to `_lseek'
  D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/lib\\libc.a(libc_a-readr.o): in function `_read_r':
  readr.c:(.text._read_r+0x24): undefined reference to `_read'
  D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/lib\\libc.a(libc_a-writer.o): in function `_write_r':
  writer.c:(.text._write_r+0x24): undefined reference to `_write'
  D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/bin/ld.exe: D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/arm-none-eabi-gcc/.content/bin/../lib/gcc/arm-none-eabi/13.3.1/../../../../arm-none-eabi/lib\\libc.a(libc_a-sbrkr.o): in function `_sbrk_r':
  sbrkr.c:(.text._sbrk_r+0x18): undefined reference to `_sbrk'
  collect2.exe: error: ld returned 1 exit status

This is done with this command line:

Executing command: D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/cmake/.content/bin/cmake.exe -DCMAKE_BUILD_TYPE=Debug -SD:/Projects/SECA/LoRa/cmake_test -BD:/Projects/SECA/LoRa/cmake_test/build/debug -G Ninja

Now if I pass in the CMAKE_MAKE_PROGRAM via command line like this:

D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/cmake/.content/bin/cmake.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=D:/Projects/SECA/LoRa/cmake_test/xpacks/@xpack-dev-tools/ninja-build/.content/bin/ninja.exe -SD:/Projects/SECA/LoRa/cmake_test -BD:/Projects/SECA/LoRa/cmake_test/build/debug -G Ninja

Then the compiler is detected correctly.

A few notes, I am setting up cmake such that for each project I can use a different version of build tools as needed. In this case the version is the same as my path version, but might not be in the future. I figured that cmake or ninja has a bug that is causing an issue.