[CMake] CMake's Ninja generator on Windows: problem with response files and Linaro's gcc compiler

[Matteo Franchin]

Hi all,
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.

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.

Rather than calling

"gcc.exe -o prog file1.o file2.o ... file9999.o file10000.o"

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:

"gcc.exe -o prog @mylongcmd.rsp"

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:

---
[676/853] Linking C static library system\libtomcrypt\liblibtomcrypt.a
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
rm-none-eabi-ar.exe cr system\libtomcrypt\liblibtomcrypt.a
@CMakeFiles/libtomcrypt.rsp && C:\linaro\bin\arm-none-eabi-ranlib.exe
system\lib
tomcrypt\liblibtomcrypt.a && cd .
C:\linaro\bin\arm-none-eabi-ar.exe:
systemlibtomcryptCMakeFileslibtomcrypt.dirsrcciphersanubis.c.obj: No such
file or directory
---

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".

What I did is then the following.  I downloaded the CMake 2.8.10 sources
and - before compiling it - I changed the line:

  bool cmGlobalNinjaGenerator::UsingMinGW = false;

to

  bool cmGlobalNinjaGenerator::UsingMinGW = true;

in the file cmake-2.8.10.2/Source/cmGlobalNinjaGenerator.cxx.
This is the only way I got it to work. I describe another attempt I made in
the post-scriptum.

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.
Cheers,
Matteo

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/2.8.10.2/" which is obtained from
CMakeCCompiler.cmake.in. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20130129/e1f1332f/attachment.htm>