Hi all,<br>I am having an issue while using CMake's Ninja generator on Windows to cross-compile some C firmware for an embedded device (ARM Cortex M3). I could solve the problem only by hacking CMake source code and recompiling it, but I am hoping somebody in this mailing list can help me to find a cleaner solution.<br>
<br>The problem I am having has to do with response files, which CMake generates in order to circumvent the limitation that Microsoft Windows has with the length of the command line (which cannot exceed 8 KB, if I am not mistaken). What CMake does is the following.<br>
<br>Rather than calling <br><br>"gcc.exe -o prog file1.o file2.o ... file9999.o file10000.o"<br><br>It prepares a file, mylongcmd.rsp, (so-called response file) containing all the command line arguments "file1.c file2.o ...". It then calls gcc like this:<br>
<br>"gcc.exe -o prog @mylongcmd.rsp"<br><br>Gcc and other tools (like ar) interpret "@mylongcmd.rsp" as an instruction to continue reading the command line arguments from the provided file. The problem I am having is that the response file ends up containing file names like "C:\directory\and\file\name.ext". Unfortunately, backslashes in response files are interpreted as special characters (for example, in "C:\files\name.ext" the sequence '\n' is interpreted as a newline character). The response file, should then rather contain something like "C:\\files\\name.ext". This problem is already partially solved in CMake's Ninja generator. Response files are correctly generated (with double backslashes) when compiling through MinGW. The problem is that I am using the Linaro gcc compiler. For this compiler, '\' is not replaced with '\\' and the compilation fails with something like:<br>
<br>---<br>[676/853] Linking C static library system\libtomcrypt\liblibtomcrypt.a<br>FAILED: cmd.exe /c cd . && "c:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E remove system\libtomcrypt\liblibtomcrypt.a && C:\linaro\bin\a<br>
rm-none-eabi-ar.exe cr system\libtomcrypt\liblibtomcrypt.a @CMakeFiles/libtomcrypt.rsp && C:\linaro\bin\arm-none-eabi-ranlib.exe system\lib<br>tomcrypt\liblibtomcrypt.a && cd .<br>C:\linaro\bin\arm-none-eabi-ar.exe: systemlibtomcryptCMakeFileslibtomcrypt.dirsrcciphersanubis.c.obj: No such file or directory<br>
---<br><br>in this case the file should be "system\libtomcrypt\CMakeFiles\libtomcrypt.dir\src\ciphers\anubis.c.obj", but the filename is interpreted (by ar) as "systemlibtomcryptCMakeFileslibtomcrypt.dirsrcciphersanubis.c.obj".<br>
<br>What I did is then the following. I downloaded the CMake 2.8.10 sources and - before compiling it - I changed the line:<br><br> bool cmGlobalNinjaGenerator::UsingMinGW = false;<br><br>to<br><br> bool cmGlobalNinjaGenerator::UsingMinGW = true;<br>
<br>in the file cmake-2.8.10.2/Source/cmGlobalNinjaGenerator.cxx.<br>This is the only way I got it to work. I describe another attempt I made in the post-scriptum.<br><br>I hope I have been sufficiently clear in explaining the issue. If not, I am happy to give further details and I am available to try different things as you may suggest.<br>
Cheers,<br>Matteo<br><br>PS: I tried also the following. After running the initial CMake to create the project directory, I
found the file CMakeCCompiler.cmake created by CMake under the directory "./CMakeFiles/<a href="http://2.8.10.2/" target="_blank">2.8.10.2/</a>" which is obtained from
<a href="http://CMakeCCompiler.cmake.in" target="_blank">CMakeCCompiler.cmake.in</a>. In this file, I replaced the line "set(CMAKE_COMPILER_IS_MINGW )"
with "set(CMAKE_COMPILER_IS_MINGW 1)". I ran ninja again, and it casued CMake to
be re-run. But the compilation ended with the same error reported above,
despite the CMakeCCompiler.cmake file was not overwritten by CMake. The reason why I tried to set this variable is because I saw it is used in the source code to set the UsingMinGW variable. I tried to set the same variable from the master CMakeLists.txt file for my project and this did not help, either.<br>
<br>