Re: [cmake-developers] cmake selftest use different compiler and binutils as configured on Darwin
On 07.07.2012, at 21:34, Nicolas Desprès wrote: I advice you to install the Apple command line tools for xcode and stop to use gcc. I have removed the path to /opt/local/bin and tested xcode without ninja: http://open.cdash.org/viewTest.php?onlyfailedbuildid=2423850 It is not clear to me what is intended with cmake selftest? * If Xcode generator is selected, sure the Bundle and other Xcode test should run * If I configure a different tool chain, i.e. mac port gcc-4.7 with all tool under /opt/local/bin, it is an ERROR to run Bundle, Architecture, and ObjC++ tests! Perhaps I must set a different CMAKE_SYSTEM_NAME, but which one? #FIXME -DCMAKE_SYSTEM_NAME=Darwin-GNU \ -DCMAKE_C_COMPILER=/opt/local/libexec/ccache/gcc \ -DCMAKE_CXX_COMPILER=/opt/local/libexec/ccache/g++ \ IMO it is a use case like cross compiling! I need a chance to control what happens. Claus -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake selftest use different compiler and binutils as configured on Darwin
This thread is not about ninja. Its about cmake self build and cmake self test after build! I have same results with Unix Makefiles generator when I use the same toolchain; http://open.cdash.org/testDetails.php?test=152892528build=2424062 http://open.cdash.org/testDetails.php?test=152794057build=2421596 The biggest problem is that ctest does not use my configured tools! I have to restrict the exported path to handle that right? Claus On 08.07.2012, at 14:47, Richard Wackerbarth wrote: Gentlemen: If you think that you have something that is working on OSX with ninja, we need to arrange to get it into next (assuming that it doesn't break anything else) At this point, it would not be enabled (by default), but some of the test systems on the nightly dashboard intentionally enable it to see how well it fairs. I am currently running two OSX tests, both with cmake from the next branch. One uses an older version of ninja that seemed stable and the other uses the latest nightly sources from the ninja repository. If we need to test some other configurations, just let me know which repositories/branches I should use for testing. Richard On Jul 8, 2012, at 5:04 AM, Claus Klein wrote: On 07.07.2012, at 21:34, Nicolas Desprès wrote: I advice you to install the Apple command line tools for xcode and stop to use gcc. I have removed the path to /opt/local/bin and tested xcode without ninja: http://open.cdash.org/viewTest.php?onlyfailedbuildid=2423850 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] How to configure target or command to preprocess C file?
Hi, I'm porting build configuration based on GNU Autotools to CMake and I have to deal with C preprocessing to generate a file. The input for preprocessor is SQL file with C preprocessor directives used, like #include another.sql, etc. Currently, Makefile uses the following rule to generate plain SQL file as output: myfile.sql: myfile.sql.in.c cpp -I../common $ | grep -v '^#' $@ So, the myfile.sql is meant to be one of products of the build process, similar to share libraries or executables. What CMake tools should I use to achieve the same effect? It's unclear to me if I should use add_custom_command, add_custom_target or combine both. Obviously, I'm looking for a portable solution that would work at least with GNU GCC and Visual Studio toolsets. I presume I will have to define platform-specific custom commands, one for cpp preprocessor, one for cl.exe. Or, does CMake provide some kind of abstraction for C-preprocessing? I scanned the archives, but I only found preprocessing of fortran files or solutions based on make capabilities (make myfile.i). So, it's not quite what I'm looking for. Could anyone help me with this? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] LINK_LIBRARIES not spilled to response file
Hello,
I posted a mail here [1] but have yet to receive any replies. I think my
last
message was too long and detailed so let me summarize:
* Command line length is limited on Windows.
* To alleviate this, CMake places object files into a response file, but the
same is not done for libraries.
* This can pose a problem when the link line becomes too long.
I am primarily interested in a solution for the Ninja generator, although
this
issue affects other generators too. My previous mail contains a testcase
and
proposed solution. In the interim another issue [2] was posted, but that is
orthogonal and does not solve what is discussed here.
Kind regards,
*--Zaheer*
*
*
[1]: http://www.cmake.org/pipermail/cmake/2012-June/051065.html
[2]: http://public.kitware.com/Bug/view.php?id=13366
On Thu, Jun 28, 2012 at 3:50 PM, Zaheer Chothia zaheer.chot...@gmail.comwrote:
Hello,
I encountered an issue while building a CMake project where one target is
linked
against a large number of libraries. Unlike object files, libraries are
not
placed into a response file, which can lead to build commands which exceed
the
length limits on Windows. For reference, I am using the CMake 2.8.9-rc1
and
Ninja generator with Microsoft compilers.
Following this mail is a testcase generator [1] to demonstrate this issue
(sample project attached for convenience). The build fails with this
error (for
readibility I replaced a long sequence of libraries with ...):
FAILED: cmd.exe /c cd. C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @hello.exe.rsp /DWIN32
/D_WINDOWS /W3 /Zm1000 /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 /Fehello.exe
/Fdhello.pdb -link /implib:hello.lib /version:0.0 /STACK:1000
/machine:X86 /debug /INCREMENTAL /subsystem:console
src\abcdefghijklmnopqrstuvwxyz0123456789\library1.lib
src\abcdefghijklmnopqrstuvwxyz0123456789\library2.lib ...
kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib comdlg32.lib advapi32.lib cd.
The command line is too long.
ninja: build stopped: subcommand failed.
Although this example may seem artificial, with the use case I refer to (i)
libraries are are specified by absolute paths so they are indeed
reasonably long
and (ii) since there are third-party libraries involved I would not be
able to
simply combine source files into one large library as is possible here. I
should also mention that this issue does not affect the Visual Studio
generators, however it is present with the following: Ninja, MinGW
Makefiles, NMake Makefiles, MSYS Makefiles. For Ninja I suspect that the
indirection via cmd.exe imposes a maximum command length of 8192 KB,
whereas for
the others this will likely be 32 KB (CreateProcess).
I would be quite content if this is fixed for the Ninja generator. A
simple fix
would be to adapt the build rules by moving $LINK_LIBRARIES from 'command'
to
'rspfile_content':
--- rules.ninja.bak 2012-06-28 15:23:35 +0100
+++ rules.ninja 2012-06-28 15:38:09 +0100
@@ -40,10 +40,10 @@
# Rule for linking C executable.
rule C_EXECUTABLE_LINKER_RSPFILE
- command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $LINK_LIBRARIES $POST_BUILD
+ command = cmd.exe /c $PRE_LINK C:\Program Files
(x86)\CMake\bin\cmake.exe -E vs_link_exe
C:\PROGRA~2\MICROS~3.0\VC\bin\cl.exe /nologo @$out.rsp $FLAGS
/Fe$out /Fd$TARGET_PDB -link /implib:$TARGET_IMPLIB /version:0.0
$LINK_FLAGS $POST_BUILD
description = Linking C executable $out
rspfile = $out.rsp
- rspfile_content = $in
+ rspfile_content = $in $LINK_LIBRARIES
Best,
--Zaheer
[1]: BEGIN: testcase.sh
---
#!/bin/bash -e
NUM_LIBRARIES=500
# Use a long path to quickly exhaust the command-line length limit.
SRC_DIR=src/abcdefghijklmnopqrstuvwxyz0123456789
# Root directory: application and CMakeLists.txt
echo int main() { return 0; } hello.c
cat EOF CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(Hello)
add_subdirectory($SRC_DIR)
add_executable(hello hello.c)
target_link_libraries(hello
EOF
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo library$i CMakeLists.txt
done
echo ) CMakeLists.txt
# Libraries: sources and CMakeLists.txt
mkdir -p $SRC_DIR
[[ -f $SRC_DIR/CMakeLists.txt ]] rm $SRC_DIR/CMakeLists.txt
for ((i = 1; i = $NUM_LIBRARIES; i++)); do
echo int function$i() { return $i; } $SRC_DIR/function$i.c
echo add_library(library$i function$i.c) $SRC_DIR/CMakeLists.txt
done
echo Testcase has been setup: now build with CMake and Ninja generator.
[1]: END: testcase.sh
---
--
[Cmake-commits] CMake branch, master, updated. v2.8.8-429-gf70f55c
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via f70f55c064d2b3a761a32b84ca39ee25377300c5 (commit) from d7e6ca5543fa935d7cf376c961ad8099edbb9cca (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f70f55c064d2b3a761a32b84ca39ee25377300c5 commit f70f55c064d2b3a761a32b84ca39ee25377300c5 Author: Kitware Robot kwro...@kitware.com AuthorDate: Mon Jul 9 00:01:02 2012 -0400 Commit: Kitware Robot kwro...@kitware.com CommitDate: Mon Jul 9 00:01:02 2012 -0400 CMake Nightly Date Stamp diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake index 74a6011..7feb0d7 100644 --- a/Source/CMakeVersion.cmake +++ b/Source/CMakeVersion.cmake @@ -2,5 +2,5 @@ SET(CMake_VERSION_MAJOR 2) SET(CMake_VERSION_MINOR 8) SET(CMake_VERSION_PATCH 8) -SET(CMake_VERSION_TWEAK 20120708) +SET(CMake_VERSION_TWEAK 20120709) #SET(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
