[cmake-developers] [CMake 0011674]: 'CMakeCXXInformation.cmake' always overrides 'CMAKE_CXX_ARCHIVE_CREATE'
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=11674 == Reported By:Harald Pohl Assigned To: == Project:CMake Issue ID: 11674 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-01-10 08:33 EST Last Modified: 2011-01-10 08:33 EST == Summary:'CMakeCXXInformation.cmake' always overrides 'CMAKE_CXX_ARCHIVE_CREATE' Description: I tried to use cmake for my ARM Keil CXX project, which is seperated into a very large library and a application project. First, everything works fine, but the source file count of my library increases that much, that windows was unable to handle the whole link command in one line. Therefore I change my compiler definition by unsetting 'CMAKE_CXX_CREATE_STATIC_LIBRARY' and setting CMAKE_C_ARCHIVE_CREATE, CMAKE_C_ARCHIVE_APPEND, CMAKE_CXX_ARCHIVE_CREATE, CMAKE_CXX_ARCHIVE_APPEND But all my values will be always overwritten by 'CMakeCInformation.cmake' or 'CMakeCXXInformation.cmake' by: 167: SET(CMAKE_C_ARCHIVE_CREATE CMAKE_AR cr TARGET LINK_FLAGS OBJECTS) 168: SET(CMAKE_C_ARCHIVE_APPEND CMAKE_AR r TARGET LINK_FLAGS OBJECTS) 169: SET(CMAKE_C_ARCHIVE_FINISH CMAKE_RANLIB TARGET) All other variables, which are set in this file, are checked for content first, exept these three. Is there a different way to prefent this? And if it's a bug, I suggest the following solution: IF(NOT CMAKE_C_ARCHIVE_CREATE) SET(CMAKE_C_ARCHIVE_CREATE CMAKE_AR cr TARGET LINK_FLAGS OBJECTS) ENDIF(NOT CMAKE_C_ARCHIVE_CREATE) IF(NOT CMAKE_C_ARCHIVE_APPEND) SET(CMAKE_C_ARCHIVE_APPEND CMAKE_AR r TARGET LINK_FLAGS OBJECTS) ENDIF(NOT CMAKE_C_ARCHIVE_APPEND) IF(NOT CMAKE_C_ARCHIVE_FINISH) SET(CMAKE_C_ARCHIVE_FINISH CMAKE_RANLIB TARGET) ENDIF(NOT CMAKE_C_ARCHIVE_FINISH) == Issue History Date ModifiedUsername FieldChange == 2011-01-10 08:33 Harald PohlNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011676]: find_package(Java) gives warning regex not supported
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11676 == Reported By:Gerhard Grimm Assigned To: == Project:CMake Issue ID: 11676 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-01-10 12:43 EST Last Modified: 2011-01-10 12:43 EST == Summary:find_package(Java) gives warning regex not supported Description: The system has HP's JRE installed in /opt/java6. The environment variable JAVA_HOME is set accordingly. When calling find_package(Java REQUIRED) in a CMakeLists.txt file, the following warning is issued: regex not supported: java version 1.6.0.06 Java(TM) SE Runtime Environment (build 1.6.0.06-jinteg_20_jan_2010_05_50-b00) Java HotSpot(TM) Server VM (build 14.3-b01-jre1.6.0.06-rc1, mixed mode). Please report Call Stack (most recent call first): CMakeLists.txt:171 (find_package) -- Java version .. configured successfully! -- Found Java: /opt/java6/bin/java (found version ..) Steps to Reproduce: 1. Obtain and install the JRE from HP (available for download from https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPUXJDKJRE60 ). 2. Set the environment variable JAVA_HOME=/opt/java6 3. Prepare a CMakeLists.txt file containing the command find_package(Java REQUIRED) 4. Call CMake using this file. Additional Information: Looking at line 108 in FindJava.cmake, it becomes clear that the version number reported by java is expected to have the format 1.6.0_06. The problem can thus be fixed by extending the regular expressions used to extract the version information (the fixed version is attached below). == Issue History Date ModifiedUsername FieldChange == 2011-01-10 12:43 Gerhard Grimm New Issue 2011-01-10 12:43 Gerhard Grimm File Added: FindJava.cmake == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011679]: CMAKE_FORCE_C_COMPILER fails to parse compiler name that contains a version number
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=11679
==
Reported By:Emmanuel Blot
Assigned To:
==
Project:CMake
Issue ID: 11679
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2011-01-10 17:14 EST
Last Modified: 2011-01-10 17:14 EST
==
Summary:CMAKE_FORCE_C_COMPILER fails to parse compiler name
that contains a version number
Description:
Using the following commands:
FIND_PROGRAM (xcc arm-eabi-gcc)
CMAKE_FORCE_C_COMPILER (${xcc} GNU)
works as expected.
RANLIB and AR commands are mapped to the same target, namely:
arm-eabi-ranlib and arm-eabi-ar
However, when a version is specified:
FIND_PROGRAM (xcc arm-eabi-gcc-4.5.2)
CMAKE_FORCE_C_COMPILER (${xcc} GNU)
RANLIB and AR commands are left to the default, host tools (which lead to later
compilation errors)
In this latter case, the _CMAKE_TOOLCHAIN_PREFIX is left empty. It seems that
the compiler string parser is in trouble.
Additional Information:
The issue occurs whatever the platform (at least tested on Cygwin and Mac OS X),
and it seems it may also occur with CMAKE_C_COMPILER.
==
Issue History
Date ModifiedUsername FieldChange
==
2011-01-10 17:14 Emmanuel Blot New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011680]: FIND_PROGRAM fails to locate a versioned compiler
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=11680
==
Reported By:Emmanuel Blot
Assigned To:
==
Project:CMake
Issue ID: 11680
Category: CMake
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2011-01-10 17:20 EST
Last Modified: 2011-01-10 17:20 EST
==
Summary:FIND_PROGRAM fails to locate a versioned compiler
Description:
This is a Cygwin-only issue.
the FIND_PROGRAM works with the following cases:
FIND_PROGRAM (xcc arm-eabi-gcc) # evaluate to /usr/local/bin/arm-eabi-gcc.exe
FIND_PROGRAM (xcc arm-eabi-gcc-4.5.2.exe) # evaluate to
/usr/local/bin/arm-eabi-gcc-4.5.2.exe
but fails to find the executable with the following case:
FIND_PROGRAM (xcc arm-eabi-gcc-4.5.2) # xcc-NOTFOUND
The latter command works on any other hosts but Windows/Cygwin.
Additional Information:
It seems that CYGWIN variable is not set to 1 either:
MESSAGE (STATUS CYGWIN: ${CYGWIN})
prints out
-- CYGWIN:
==
Issue History
Date ModifiedUsername FieldChange
==
2011-01-10 17:20 Emmanuel Blot New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Generating information for C++ tools in cmake (patch)
Hi,
we're working on C++ tools based on clang to get the power of
automated refactoring and analysis that Java has known for years to
C++ developers.
With the attached patch I include a proposal for how we could export
the compile command line for C/C++ files from cmake for Unix makefile
generators:
The idea is to output a small JSON database with all C/C++ files in
the project, which contains
- the file's path
- the working directory in which the compile runs
- the compile command
Background:
While C++ refactoring and analysis tools are not compilers, and thus
don't run as part of the build system, they need the exact information
of a build in order to be able to correctly understand the C++ code of
the project. The natural candidate to export that information is the
build system. We chose cmake to provide a first implementation, as
cmake is the current open source standard build system for large scale
C++ projects (like clang itself), and as such it is in the best
position to define a standard way to make compile commands accessible
for tools in the open source world.
Example tools:
- running clang -fsyntax-only over source code from an editor to get
fast syntax checks
- running match/replace tools over C++ code (a project we're currently
working on)
Any feedback would be highly appreciated. If you think the way this is
implemented is a dumb idea (which it probably is), please tell me - I
don't have a lot of experience in the cmake architecture. Also, if you
object to the idea of exporting this information in general, please
let me know.
Thanks a lot,
/Manuel
diff --git a/Source/cmGlobalUnixMakefileGenerator3.cxx b/Source/cmGlobalUnixMakefileGenerator3.cxx
index d9a341c..92f87c9 100644
--- a/Source/cmGlobalUnixMakefileGenerator3.cxx
+++ b/Source/cmGlobalUnixMakefileGenerator3.cxx
@@ -31,6 +31,7 @@ cmGlobalUnixMakefileGenerator3::cmGlobalUnixMakefileGenerator3()
#else
this-UseLinkScript = true;
#endif
+ this-CommandDatabase = NULL;
}
void cmGlobalUnixMakefileGenerator3
@@ -139,6 +140,17 @@ void cmGlobalUnixMakefileGenerator3
}
//
+std::string EscapeJSON(const std::string s) {
+ std::string result;
+ for (int i = 0; i s.size(); ++i) {
+if (s[i] == '' || s[i] == '\\') {
+ result += '\\';
+}
+result += s[i];
+ }
+ return result;
+}
+
void cmGlobalUnixMakefileGenerator3::Generate()
{
// first do superclass method
@@ -189,6 +201,35 @@ void cmGlobalUnixMakefileGenerator3::Generate()
// write the main makefile
this-WriteMainMakefile2();
this-WriteMainCMakefile();
+
+ if (this-CommandDatabase != NULL) {
+*this-CommandDatabase std::endl ];
+delete this-CommandDatabase;
+this-CommandDatabase = NULL;
+ }
+}
+
+void cmGlobalUnixMakefileGenerator3::AddCXXCompileCommand(
+const std::string sourceFile, const std::string workingDirectory,
+const std::string compileCommand) {
+ if (this-CommandDatabase == NULL)
+{
+std::string commandDatabaseName =
+ std::string(this-GetCMakeInstance()-GetHomeOutputDirectory())
+ + /cxx_commands.json;
+this-CommandDatabase =
+ new cmGeneratedFileStream(commandDatabaseName.c_str());
+*this-CommandDatabase [ std::endl;
+} else {
+*this-CommandDatabase , std::endl;
+}
+ *this-CommandDatabase { std::endl
+ \directory\: \ EscapeJSON(workingDirectory) \,
+ std::endl
+ \command\: \ EscapeJSON(compileCommand) \,
+ std::endl
+ \file\: \ EscapeJSON(sourceFile) \
+ std::endl };
}
void cmGlobalUnixMakefileGenerator3::WriteMainMakefile2()
diff --git a/Source/cmGlobalUnixMakefileGenerator3.h b/Source/cmGlobalUnixMakefileGenerator3.h
index cdc9460..a152e01 100644
--- a/Source/cmGlobalUnixMakefileGenerator3.h
+++ b/Source/cmGlobalUnixMakefileGenerator3.h
@@ -112,6 +112,10 @@ public:
/** Record per-target progress information. */
void RecordTargetProgress(cmMakefileTargetGenerator* tg);
+ void AddCXXCompileCommand(const std::string sourceFile,
+const std::string workingDirectory,
+const std::string compileCommand);
+
protected:
void WriteMainMakefile2();
void WriteMainCMakefile();
@@ -178,6 +182,8 @@ protected:
size_t CountProgressMarksInTarget(cmTarget* target,
std::setcmTarget* emitted);
size_t CountProgressMarksInAll(cmLocalUnixMakefileGenerator3* lg);
+
+ cmGeneratedFileStream *CommandDatabase;
};
#endif
diff --git a/Source/cmMakefileTargetGenerator.cxx b/Source/cmMakefileTargetGenerator.cxx
index 9dcd8f1..c14b789 100644
--- a/Source/cmMakefileTargetGenerator.cxx
+++ b/Source/cmMakefileTargetGenerator.cxx
@@ -249,6 +249,62 @@ void cmMakefileTargetGenerator::WriteCommonCodeRules()
}
//
+std::string cmMakefileTargetGenerator::GetFlags(const
