View Issue Details [ Jump to Notes ]

[ Print ]

Project

Category

View Status

Date Submitted

Last Update

0012286

CMake

public

2011-06-19 13:08

2011-06-20 13:26

Reporter

Jérôme Gardou

Assigned To

Priority

normal

Severity

tweak

Reproducibility

always

Status

closed

Resolution

no change required

Platform

MinGW - ccache

Windows

OS Version

Product Version

CMake 2.8.4

Target Version

Fixed in Version

Summary

0012286: Includes should be with unix path style when CMAKE_<LANG>_USE_RESPONSE_FILE_FOR_INCLUDES is set

Description

For the reactos progject, we would like to use ccache to speed up compilation.

Unfortunately, cmake uses Response files to set includes of source files (like @Cmakefiles/target.dir/includes_C.rsp) and ccache doesn't support that.

Fortunately, we can set the CMAKE_<LANG>_USE_RESPONSE_FILE_FOR_INCLUDES variable to OFF and cmake will stop generating such files and will concatenate them to the flags. But it will use the windows path style, ie -IX:\some\path\to\some\header.h which is wrong.

You could as well use unix path style, or double backslashes. Please find the attached patch. This shouldn't break anything, all compiler I know of support the "/" path separator.

Steps To Reproduce

Create any module with MinGW (no need to use ccache) with the CMAKE_C_USE_RESPONSE_FILE_FOR_INCLUDES set to OFF, and see the result.

Tags

No tags attached.

Attached Files

0002-Use-unix-path-style-for-includes-when-CMAKE_-LANG-_U.patch [^] (857 bytes) 2011-06-19 13:08 [Show Content] [Hide Content]

From 7ce4a71097a2f76c797e067230c89de6d8605b3b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Gardou?= <jerome.gardou@laposte.net>
Date: Sun, 19 Jun 2011 18:55:44 +0200
Subject: Use unix path style for includes when CMAKE_<LANG>_USE_RESPONSE_FILE_FOR_INCLUDES is set

---
 Source/cmMakefileTargetGenerator.cxx |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/Source/cmMakefileTargetGenerator.cxx b/Source/cmMakefileTargetGenerator.cxx
index d0df8f0..714e4b7 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -1796,6 +1796,7 @@ void cmMakefileTargetGenerator::AddIncludeFlags(std::string& flags,
     }
   else
     {
+    cmSystemTools::ConvertToUnixSlashes(includeFlags);
     this->LocalGenerator->AppendFlags(flags, includeFlags.c_str());
     }
 }
-- 
1.7.3.1.msysgit.0

Relationships

Notes
(0026914) Brad King (manager) 2011-06-20 09:15	We started using response files for include paths here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a0b9bc8 [^] http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=86cb17b1 [^] because some projects use really long include path lists that the mingw32-make shell could not handle. Patch 0002-Use-unix-path-style-for-includes-when-CMAKE_-LANG-_U.patch modifies AddIncludeFlags which is only about the final command line generation. Path conversion has already taken place by that point so converting it back is incorrect. CMake stores all paths internally using forward slashes. Then the generators convert to the proper slashes at the end. The cmLocalGenerator::GetIncludeFlags method calls Convert methods to format file paths for generation into the build system. It is not wrong to use backslashes in this context. The flags appear on a command line for a Windows shell inside mingw32-make.

(0026916) Jérôme Gardou (reporter) 2011-06-20 11:52	OK, but then it should use x:\\some\\Path, as doing otherwise breaks compilation. IMHO, all windows path should be defined that way.

(0026917) Brad King (manager) 2011-06-20 11:52 edited on: 2011-06-20 11:53	Does it break compilation without ccache? We've been using backslashes in this generator for YEARS and never seen a problem.

(0026919) Jérôme Gardou (reporter) 2011-06-20 11:58	Good point, if you don't experience any problem, then it's likely to be ccache fault. I guess I'll have to work a patch on their side. Thanks for pointing this out. BTW, what about using some make variable such as C_INCLUDES (along with C_FLAGS and C_DEFINES) defined in flags.make instead of adding yet another file dependency? This way you wouldn't need any gcc 3.x special variable.

(0026920) Brad King (manager) 2011-06-20 12:01	C_INCLUDES instead of response files? The reason for the response file is not a limitation of the make tool. The windows command line cannot exceed 32K bytes or so (I think it is a CreateProcess API limitation). Projects with really long paths to their source/build trees and lots of include directories cannot build unless the long lists are left out of the command line invocation.

(0026921) Jérôme Gardou (reporter) 2011-06-20 12:37 edited on: 2011-06-20 12:54	OK... Anyway, thanks for pointing me in the right direction. I guess you can close the bug now. EDIT : btw, if you look at the response file, you'll notice that paths are unix-styled. That's what made me think it was a cmake bug.

(0026922) Brad King (manager) 2011-06-20 13:26	Re 0012286:0026921: The response files use forward slashes because that is what gcc's documentation requires. I understand the confusion. Good discussion.

Issue History
Date Modified	Username	Field	Change
2011-06-19 13:08	Jérôme Gardou	New Issue
2011-06-19 13:08	Jérôme Gardou	File Added: 0002-Use-unix-path-style-for-includes-when-CMAKE_-LANG-_U.patch
2011-06-20 09:04	Brad King	Status	new => backlog
2011-06-20 09:15	Brad King	Note Added: 0026914
2011-06-20 11:52	Jérôme Gardou	Note Added: 0026916
2011-06-20 11:52	Brad King	Note Added: 0026917
2011-06-20 11:53	Brad King	Note Edited: 0026917
2011-06-20 11:58	Jérôme Gardou	Note Added: 0026919
2011-06-20 12:01	Brad King	Note Added: 0026920
2011-06-20 12:37	Jérôme Gardou	Note Added: 0026921
2011-06-20 12:54	Jérôme Gardou	Note Edited: 0026921
2011-06-20 13:26	Brad King	Note Added: 0026922
2011-06-20 13:26	Brad King	Status	backlog => closed
2011-06-20 13:26	Brad King	Resolution	open => no change required