[CMake] Compilation speed with CMake/NMake combination, making it faster?
So we've got a fairly sizable amount of code described in the CMake framework now, about 10 or so libraries, and 4 projects which consume them. We're now hitting upon compilation time as an issue, as it takes much longer than our previous framework did. I'm wondering what can be done to speed it up. My thoughts on the matter are: * We're using an NMake build tree, is NMake particularly slow? Do any of the other makes work more efficiently? * Does all the percentage complete processing add a significant overhead to the build time? * It seems to take CMake/NMake a long time to determine that no work needs to be done. It can take 20 seconds or longer for all the dependency targets to be checked, no work to be done, and only then will the project start compiling. Does anyone have any thoughts on this matter? I'd appreciate any ideas on how to speed this up. Thanking you, Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Compilation speed with CMake/NMake combination, making it faster?
* We're using an NMake build tree, is NMake particularly slow? Do any of the other makes work more efficiently? Be aware that nmake builds are much slower than using devenv, as nmake starts a cl.exe process for every single file, whereas devenv calls cl.exe with several source files. This costs, due to the high process overhead on Windows. -Torsten This e-mail and any files sent with it contain information that may be privileged or confidential and is the property of the GateHouse Group. This information is intended solely for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use the message or any part thereof. If you have received this e-mail in error, please notify the sender immediately, and delete all copies of this message. In accordance with GateHouse Security Policy, e-mails sent or received may be monitored. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Bug with cmake's `--debug-trycompile' option?
I have a CMakeLists.txt like this: PROJECT(foo) SET(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE) INCLUDE(CheckIncludeFile) CHECK_INCLUDE_FILE(poll.h VAR1) CHECK_INCLUDE_FILE(sys/event.h VAR2) When I run `cmake .' it outputed like this: -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Looking for poll.h -- Looking for poll.h - found -- Looking for sys/event.h -- Looking for sys/event.h - not found -- Configuring done -- Generating done -- Build files have been written to: /root/void/cmake/check_include_file/build This is fine for `sys/event.h' is not available on my system. But when I run `cmake --debug-trycompile .' it outputed like this: debug trycompile on -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Looking for poll.h -- Looking for poll.h - found -- Looking for sys/event.h -- Looking for sys/event.h - found -- Configuring done -- Generating done -- Build files have been written to: /root/void/cmake/check_include_file/build This time it said that `sys/event.h' was found! Anything wrong? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
RE: [CMake] Compilation speed with CMake/NMake combination, making it faster?
-Original Message- From: Torsten Martinsen [mailto:[EMAIL PROTECTED] Sent: 11 December 2007 09:08 To: Josef Karthauser; CMake ML Subject: RE: [CMake] Compilation speed with CMake/NMake combination, making it faster? * We're using an NMake build tree, is NMake particularly slow? Do any of the other makes work more efficiently? Be aware that nmake builds are much slower than using devenv, as nmake starts a cl.exe process for every single file, whereas devenv calls cl.exe with several source files. This costs, due to the high process overhead on Windows. I understand that. I'm still interested in hearing from folks how might have optimised this though. Our builds feel much slower than I'd expect from previous experience with make file driven builds. Joe ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] What does this mean: IF(${VARIABLE} MATCHES ^${VARIABLE}$)
The header of many CMake modules often looks like this (take
CheckIncludeFile as an example):
MACRO(CHECK_INCLUDE_FILE INCLUDE VARIABLE)
IF(${VARIABLE} MATCHES ^${VARIABLE}$)
... ...
The IF statement really puzzles me a lot. What is it used to do?
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
On Dec 10, 2007 8:58 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2007-12-10 17:08+0100 Tristan Carel wrote:
On Dec 10, 2007 7:15 AM, Alan W. Irwin [EMAIL PROTECTED] wrote:
On 2007-12-10 05:33+0100 Christiaan Putter wrote:
Hi all,
I know swig support isn't all that great at the moment but was wondering
if
someone happens to have a working Swig module for cmake that doesn't
rebuild
every time even without the dependencies having changed.
I do confirm that is a problem, and I hope somebody fixes it.
I use the Swig module, the one provided by CMake, and it's working
well. Swig wrappers generation and library compilation are properly
managed (not rebuild all the time). I use it the same way than Alan
described: only one swig file, which takes care of all inclusions, is
provided to the macro SWIG_ADD_MODULE. To specify missing
dependencies, I use the variable `SWIG_MODULE_module_EXTRA_DEPS':
One weakness of the previous PLplot implementation was the lack of
dependency on the common file, but now I am using
SWIG_MODULE_module_EXTRA_DEPS to provide that. Thanks for drawing my
attention to that possibility.
However, that is a side issue from the problem that swig is always re-invoked
(for the PLplot case) which means the interface always gets rebuilt. Here
are some more details.
CMakeLists.txt fragment:
# This is currently the include list for swig, the C wrapper and the
# the Python headers. Not particular pretty...
set(python_interface_INCLUDE_PATHS
${CMAKE_SOURCE_DIR}/include
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/include
${CMAKE_CURRENT_BINARY_DIR}
${PYTHON_INCLUDE_PATH}
${CMAKE_SOURCE_DIR}/bindings/swig-support
)
include_directories(${python_interface_INCLUDE_PATHS})
set(CMAKE_SWIG_FLAGS -DPL_DOUBLE -DSWIG_PYTHON -python)
set(CMAKE_SWIG_OUTDIR ${CMAKE_CURRENT_BINARY_DIR})
set(SWIG_MODULE_plplotcmodule_EXTRA_DEPS
${CMAKE_SOURCE_DIR}/bindings/swig-support/plplotcapi.i)
# Set up swig + c wrapper.
# N.B. the python target has an underscore prepended automatically.
swig_add_module(plplotcmodule python plplotcmodule.i)
swig_link_libraries(plplotcmodule plplot${LIB_TAG} ${PYTHON_LIBRARIES})
If I rerun make, here is the (partial) verbose result showing that swig is
re-run, then the interface is rebuilt:
[...]
I get the same gratuitous rebuild behaviour for our Java interface as well.
Tristan, since you do not encounter this problem, are you doing something
qualitatively different than above in your CMakeLists.txt file?
I use `UseSWIG' the same way you do (except the unecessary `-python'
in CMAKE_SWIG_FLAGS, already added by the module when you specify the
target language in SWIG_ADD_MODULE macro). `UseSWIG.cmake' intends to
be smart and takes cares of *all* files generated by swig: not only
c/c++ code, but also wrappers in target language.
UseSwig.cmake uses basename of swig file to determine target language files.
So, do you have %module plplotcmodule or %module plpotc in the plplotcmodule.i?
This constraint on the filename can be quite inconvenient, furthermore
this does not work with Java wrappers :)
so here is a patch:
--- /home/carel/CMake/CMake/Modules/UseSWIG.cmake 2007-03-05
21:21:49.0 +0100
+++ /usr/local/share/cmake-2.5/Modules/UseSWIG.cmake2007-12-11
10:31:38.0 +0100
@@ -18,7 +18,8 @@
SET(SWIG_CXX_EXTENSION cxx)
SET(SWIG_EXTRA_LIBRARIES )
-SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION py)
+SET(SWIG_PYTHON_EXTRA_FILE_EXTENSION .py)
+SET(SWIG_JAVA_EXTRA_FILE_EXTENSION JNI.java .java)
#
# For given swig module initialize variables associated with it
@@ -48,9 +49,15 @@
#
MACRO(SWIG_GET_EXTRA_OUTPUT_FILES language outfiles generatedpath infile)
- FOREACH(it ${SWIG_PYTHON_EXTRA_FILE_EXTENSION})
+ GET_SOURCE_FILE_PROPERTY(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename
+${infile} SWIG_MODULE_NAME)
+ IF(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename STREQUAL NOTFOUND)
+GET_FILENAME_COMPONENT(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename
${infile} NAME_WE)
+ ENDIF(SWIG_GET_EXTRA_OUTPUT_FILES_module_basename STREQUAL NOTFOUND)
+ FOREACH(it ${SWIG_${language}_EXTRA_FILE_EXTENSION})
SET(${outfiles} ${${outfiles}}
- ${generatedpath}/${infile}.${it})
+ ${generatedpath}/${SWIG_GET_EXTRA_OUTPUT_FILES_module_basename}${it})
ENDFOREACH(it)
ENDMACRO(SWIG_GET_EXTRA_OUTPUT_FILES)
@@ -105,7 +112,7 @@
SWIG_GET_EXTRA_OUTPUT_FILES(${SWIG_MODULE_${name}_LANGUAGE}
swig_extra_generated_files
${swig_outdir}
-${swig_source_file_name_we})
+${infile})
SET(swig_generated_file_fullname
${swig_generated_file_fullname}/${swig_source_file_name_we})
# add the language into the name of the file (i.e. TCL_wrap)
So in case the module name is different than the file's basename, you
can add a property SWIG_MODULE_NAME to swig files provided to the
`SWIG_ADD_MODULE' macro in order to force the module name defined by
these files:
SET_SOURCE_FILES_PROPERTIES(callback.i
Re: [CMake] escaping!
I'm quite jaded about keeping CMakeLists.txt simple. As far as I'm concerned, it should be as simple as the level of complication of your build. If I want encapsulation, I write a macro. Otherwise I'll just write straight CMake script, because I'd rather read CMake script than the docs of 5 different Unixy tools that all do their own kind of regular expression processing. I second this. We have a pretty big project and installer generation framework using CMake technology and it is very valuable to learn and master CMake scripting for a long-terme development. If everything is done with CMake you get more consistency and an easy and natural way to get access to your framework variables. Here is my advice: First think about how to do it the CMake way,then if it's not doable (which is pretty rare) do it with some other language. man cmake is your best friend ;-) --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] escaping!
I'm quite jaded about keeping CMakeLists.txt simple. As far as I'm concerned, it should be as simple as the level of complication of your build. If I want encapsulation, I write a macro. Otherwise I'll just write straight CMake script, because I'd rather read CMake script than the docs of 5 different Unixy tools that all do their own kind of regular expression processing. I second this. We have a pretty big project and installer generation framework using CMake technology and it is very valuable to learn and master CMake scripting for a long-terme development. If everything is done with CMake you get more consistency and an easy and natural way to get access to your framework variables. Here is my advice: First think about how to do it the CMake way,then if it's not doable (which is pretty rare) do it with some other language. man cmake is your best friend ;-) --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: RE: [CMake] Compilation speed with CMake/NMake combination, making it faster?
Von: Josef Karthauser [EMAIL PROTECTED] -Original Message- From: Torsten Martinsen [mailto:[EMAIL PROTECTED] Sent: 11 December 2007 09:08 To: Josef Karthauser; CMake ML Subject: RE: [CMake] Compilation speed with CMake/NMake combination, making it faster? * We're using an NMake build tree, is NMake particularly slow? Do any of the other makes work more efficiently? Be aware that nmake builds are much slower than using devenv, as nmake starts a cl.exe process for every single file, whereas devenv calls cl.exe with several source files. This costs, due to the high process overhead on Windows. I understand that. It's not a nmake problem but a problem of cmake. cmake does not support batched build - already opened a bug long time ago because of this. Christian -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does this mean: IF(${VARIABLE} MATCHES ^${VARIABLE}$)
Quoting Clark J. Wang [EMAIL PROTECTED]:
The header of many CMake modules often looks like this (take
CheckIncludeFile as an example):
MACRO(CHECK_INCLUDE_FILE INCLUDE VARIABLE)
IF(${VARIABLE} MATCHES ^${VARIABLE}$)
... ...
The IF statement really puzzles me a lot. What is it used to do?
In strings it would mean if this string is exactly equal to. The
caret (^) represents string beginning and the $ represents string end.
Why is IF(${VARIABLE} MATCHES ^${VARIABLE}$) used instead of IF(
${VARIABLE} STREQUAL ${VARIABLE} ) (which would always return true)?
I'm not sure of use case but I'd say it's checking for special
characters in VARIABLE.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does this mean: IF(${VARIABLE} MATCHES ^${VARIABLE}$)
On Dec 11, 2007 6:49 PM, Pau Garcia i Quiles [EMAIL PROTECTED] wrote:
Quoting Clark J. Wang [EMAIL PROTECTED]:
The header of many CMake modules often looks like this (take
CheckIncludeFile as an example):
MACRO(CHECK_INCLUDE_FILE INCLUDE VARIABLE)
IF(${VARIABLE} MATCHES ^${VARIABLE}$)
... ...
The IF statement really puzzles me a lot. What is it used to do?
In strings it would mean if this string is exactly equal to. The
caret (^) represents string beginning and the $ represents string end.
Why is IF(${VARIABLE} MATCHES ^${VARIABLE}$) used instead of IF(
${VARIABLE} STREQUAL ${VARIABLE} ) (which would always return true)?
I'm not sure of use case but I'd say it's checking for special
characters in VARIABLE.
If it's checking for special characters then I have to say that it's not the
right way. For example, if VARIABLE == a/b then the IF statement is still
TRUE.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compilation speed with CMake/NMake combination, making it faster?
Christian Ehrlicher wrote: * We're using an NMake build tree, is NMake particularly slow? Do any of the other makes work more efficiently? Be aware that nmake builds are much slower than using devenv, as nmake starts a cl.exe process for every single file, whereas devenv calls cl.exe with several source files. This costs, due to the high process overhead on Windows. I understand that. It's not a nmake problem but a problem of cmake. cmake does not support batched build - already opened a bug long time ago because of this. I am not sure how much faster a batch build would be. The real issue is the dual or more core machines. Even with a batch build and cl, it still only uses one processor, where devenv uses more. I use gmake and cl to get around this with -j N. However, gmake is slower than nmake because it uses the POSIX stat which is VERY slow on Windows. Someday I am going to hack gmake to use the Windows native calls to stat files. I almost think that would be time better spent than adding batch cl calls to CMake. I would like to see some bench marks on cl batch builds. It will not be trivial to implement and I don't think it would be worth the effort unless it has a big gain. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does this mean: IF(${VARIABLE} MATCHES ^${VARIABLE}$)
Jian Wang wrote:
Why is IF(${VARIABLE} MATCHES ^${VARIABLE}$) used instead of IF(
${VARIABLE} STREQUAL ${VARIABLE} ) (which would always return true)?
I'm not sure of use case but I'd say it's checking for special
characters in VARIABLE.
If it's checking for special characters then I have to say that it's not
the right way. For example, if VARIABLE == a/b then the IF statement
is still TRUE.
It is checking to see if the VARIABLE has a value at all. It is old
code before we had IF(DEFINED VARIABLE) but works with all versions of
CMake.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Including of Platform/UnixPaths.cmake now broken
On Dec 10, 2007, at 5:33 PM, Gonzalo Garramuño wrote: I use my own variable -DCMAKE_BUILD_ARCH=32 to determine whether I am compiling 32-bits on a 64-bits machine. The problem is that cmake now goes to check compiler and it runs Platform/UnixPaths.cmake without passing any of my variables to it (ie. CMAKE_BUILD_ARCH=). CMake can be quite finicky about how variables are passed in from the command line. The correct syntax is: -DVAR_NAME:TYPE=VAL Try: -DCMAKE_BUILD_ARCH:STRING=32 and see if you still have problems. If you don't see it on the very first page in ccmake, then it didn't pick it up properly. Sadly, cmake doesn't give warnings or errors if the other form is used (-DVAR_NAME=VAL). It just behaves erratically. James___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross-directory dependencies?
Bryan O'Sullivan wrote: I have two sibling directories. In one of them, a binary is built, and in the other, that binary is packaged up using a custom command. Is there a way in the DEPENDS clause to express this dependency? There are two levels of dependencies: file and target. File-level dependencies are evaluated within each target to actually update the build. Target-level dependencies make sure that entire targets are up to date before others even begin building (or evaluating file-level dependencies). Target-level dependencies are good across directories too. You should just be able to do add_dependencies(my_packager_target my_exe_target) in the directory with the custom command/target that does the packaging. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building debug targets
The quotes may be confusing... Try this exactly, with the quotes surrounding the whole thing, or without the quotes: -DCMAKE_BUILD_TYPE:STRING=Debug I think you are telling it to set the build type to Debug (including the quotes) but for it to work, it needs to be exactly Debug without any quotes... HTH, David On 12/10/07, Ramazan Girgin [EMAIL PROTECTED] wrote: Hi all, I want to built debug target with cmake and nmake . I am calling cmake with -DCMAKE_BUILD_TYPE=Debug.later i am calling nmake. But everytime nmake is building release target. Is there any other way to build debug target??? Thanks in advance Ramazan ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compilation speed with CMake/NMake combination, making it faster?
Bill Hoffman wrote: Christian Ehrlicher wrote: * We're using an NMake build tree, is NMake particularly slow? Do any of the other makes work more efficiently? Be aware that nmake builds are much slower than using devenv, as nmake starts a cl.exe process for every single file, whereas devenv calls cl.exe with several source files. This costs, due to the high process overhead on Windows. I understand that. It's not a nmake problem but a problem of cmake. cmake does not support batched build - already opened a bug long time ago because of this. I am not sure how much faster a batch build would be. The real issue is the dual or more core machines. Even with a batch build and cl, it still only uses one processor, where devenv uses more. I use gmake and cl to get around this with -j N. However, gmake is slower than nmake because it uses the POSIX stat which is VERY slow on Windows. Someday I am going to hack gmake to use the Windows native calls to stat files. I almost think that would be time better spent than adding batch cl calls to CMake. I would like to see some bench marks on cl batch builds. It will not be trivial to implement and I don't think it would be worth the effort unless it has a big gain. This is not scientific but I wrote a quick perl script to compile a simple library that we use (GCTPc). It consists of 70 C files with most of the files between 5K and 6K, a few are as large as 70K. The script just uses the time() function to grab the elapsed seconds and runs three tests. The first runs one cl.exe process with all 70 files with the '-c' flag to only compile. The second compiles each C file with it's own invocation of cl.exe. The last repeats the first, but with the new, experimental, '/MP' flag that does multiprocessor builds. I get the following times for these files: all files : 2 seconds single files : 7 seconds mp build : 1 second I repeated this test with a set of 15 C++ files that are larger with template code and that take significantly longer and I got the following times: all files : 60 seconds single files : 78 seconds mp build : 51 seconds So, even on the single processor build the single invocation is almost 25% faster. Take it all with a grain of salt. Jason ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compilation speed with CMake/NMake combination, making it faster?
2007/12/11, Jason Stewart [EMAIL PROTECTED]: This is not scientific but I wrote a quick perl script to compile a simple library that we use (GCTPc). It consists of 70 C files with most of the files between 5K and 6K, a few are as large as 70K. The script just uses the time() function to grab the elapsed seconds and runs three tests. The first runs one cl.exe process with all 70 files with the '-c' flag to only compile. The second compiles each C file with it's own invocation of cl.exe. The last repeats the first, but with the new, experimental, '/MP' flag that does multiprocessor builds. I get the following times for these files: all files : 2 seconds single files : 7 seconds mp build : 1 second I repeated this test with a set of 15 C++ files that are larger with template code and that take significantly longer and I got the following times: all files : 60 seconds single files : 78 seconds mp build : 51 seconds So, even on the single processor build the single invocation is almost 25% faster. Take it all with a grain of salt. I'm not a big MS Platform user but I like the idea of compilation speed-up very much. I personnally use ccache (http://ccache.samba.org/) on Linux + gcc and there is x2 up to x4 _SPEEDUP_ (when recompiling since initial compilation is slower) on a C++ project with 50+ files with moderate template usage. It seems that somebody did port ccache to work with MS CL: http://artax.karlin.mff.cuni.cz/~kendy/blog/ http://artax.karlin.mff.cuni.cz/~kendy/ccache/ May be you can try it? -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Compilation speed with CMake/NMake combination, making it faster?
* We're using an NMake build tree, is NMake particularly slow? Do any of the other makes work more efficiently? Be aware that nmake builds are much slower than using devenv, as nmake starts a cl.exe process for every single file, whereas devenv calls cl.exe with several source files. This costs, due to the high process overhead on Windows Maybe using compilation units might help.With devenv, we get up to x9 faster compilation time using them (usually only one or two compilation units for each project). --Sylvain ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What does this mean: IF(${VARIABLE} MATCHES ^${VARIABLE}$)
On Dec 11, 2007 8:16 AM, Bill Hoffman [EMAIL PROTECTED] wrote:
Jian Wang wrote:
Why is IF(${VARIABLE} MATCHES ^${VARIABLE}$) used instead of IF(
${VARIABLE} STREQUAL ${VARIABLE} ) (which would always return true)?
I'm not sure of use case but I'd say it's checking for special
characters in VARIABLE.
If it's checking for special characters then I have to say that it's not
the right way. For example, if VARIABLE == a/b then the IF statement
is still TRUE.
It is checking to see if the VARIABLE has a value at all. It is old
code before we had IF(DEFINED VARIABLE) but works with all versions of
CMake.
One of these days I'm going to try to construct a pathological input
to make it barf. But I've still got other priorities.
Cheers,
Brandon Van Every
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] What's happening to CMake ??? Please help !!!
Hello CMake users developers, I've been trying to build ITK on my machine, and obviously is not related to what is built, and CMake produces some errors at the configuration step. Perhaps someoneelse has already encountered similar type of problem ? My setup: Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.4, Visual Studio .NET 2005 w/ Visual C++ 8 At first I've observed the following CMake Errror message box and then a lot of errors coming up when I choose OK. CMake Error: Unable to find executable for TRY_RUN: tried Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe and Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe and Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe. [CMake is correct; these files do not exist, but the log indicates no error for the building of these executables.] I've compiled previous version of ITK, or VTK, etc. without any problem before, but after deleting old one and trying to build the latest release, I've got these errors. I'd be grateful to anyone who help me resolve this problem ? Sincerely Cem DEMiRKIR ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] What's happening to CMake ??? Please help !!!
CMake 2.4.4 had some serious flaws and was only available for a very short time before being fixed by 2.4.5 Update to the latest CMake release (2.4.7) and try again. And don't forget to start over with an empty binary directory after updating CMake... HTH, David On 12/11/07, Cem DEMiRKIR [EMAIL PROTECTED] wrote: Hello CMake users developers, I've been trying to build ITK on my machine, and obviously is not related to what is built, and CMake produces some errors at the configuration step. Perhaps someoneelse has already encountered similar type of problem ? My setup: Windows XP, ITK 3.4.0 Latest Release, CMake 2.4.4, Visual Studio .NET 2005 w/ Visual C++ 8 At first I've observed the following CMake Errror message box and then a lot of errors coming up when I choose OK. CMake Error: Unable to find executable for TRY_RUN: tried Z:\Libraries\Insight\bin/CMakeTmp/cmTryCompileExec.exe and Z:\Libraries\Insight\bin/CMakeTmp/Debug/cmTryCompileExec.exe and Z:\Libraries\Insight\bin/CMakeTmp/Development/cmTryCompileExec.exe. [CMake is correct; these files do not exist, but the log indicates no error for the building of these executables.] I've compiled previous version of ITK, or VTK, etc. without any problem before, but after deleting old one and trying to build the latest release, I've got these errors. I'd be grateful to anyone who help me resolve this problem ? Sincerely Cem DEMiRKIR ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 4
It's something more than just this simple example... I've tried it with CMake 2.4.5, 2.4.7 and today's CVS CMake and it does not happen on my machine. (The Debug C always properly links to Ad only, not also to A...) I am using VS 2005 standard edition. The problem was occurring on the ParaView3 dashboards (until I masked it out by mucking with CXX_FLAGS last Friday) on morva and minastirith dashboards. Here's an example: http://www.paraview.org/ParaView3/Testing/Sites/morva.kitware/Win32-vs8/20071207-0100-Nightly/BuildWarning.html morva is using CMake 2.4.5 and VS8 Professional edition, minastirith is using CMake 2.4.7 and VS8 Standard edition. Any other clues about what additional steps / settings might be required to trigger this error condition? On 12/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Can this be fixed for 2.4.8? It looks like it was already fixed for 2.6, but I couldn't find a bug report for it. = ADD_LIBRARY(A a.c) ADD_LIBRARY(Ad a.c) ADD_LIBRARY(B b.c) TARGET_LINK_LIBRARIES(B debug Ad optimized A) # if building shared libs, cmake correctly links B with -lAd OR -lA ADD_EXECUTABLE(C c.c) TARGET_LINK_LIBRARIES(C B) # cmake incorrectly links C with -lB -lAd -lA if build type is Debug === Clint On Wednesday 05 December 2007 3:13:39 pm Bill Hoffman wrote: I have a beta release for 2.4.8 ready for cmake. This will be the last release of the 2.4.X branch. The next release will be 2.6.0. So, please make sure you test it if you are interested in a 2.4.8. Send any issues to me or the cmake list. Thanks. The files can be found here: http://www.cmake.org/files/v2.4/*RC-4* The changes from 2.4.7 are as follows: Changes in CMake 2.4.8 RC 4 * fix for cpack and messing up PATH with NSIS Changes in CMake 2.4.8 RC 3 * fix for bug 5363: GET_TARGET_PROPERTY(... DEBUG_LOCATION) returns value containing $(OutDir) * Better error from ctest if nightly time not set * Fix for exception handling flags in VS 2003 and up * Avoid relinking exclude-from-all directory targets before install Changes in CMake 2.4.8 RC 2 * fix for bug 5590 relative paths in windows not working across drives * fix warning/error with TAR_VERBOSE flag Changes in CMake 2.4.8 RC 1 * Fix for kde4-config location * Fix for self extracting .sh files on solaris * Remove KDE3_ENABLE_FINAL (did not work) * KDE3 fix for 64 bit location of plugins * mark PYTHON_EXECUTABLE as advanced * Fix for version numbers on NetBSD * Add more search directories (install prefix and cmake location) * include WindowsPaths in Windows.cmake not just Windows-cl.cmake * documentation fix for file, find_package, try_run * add IS_ABSOLUTE to if * INSTALL() everything which doesn't have a COMPONENT set, is assigned to the COMPONENT Unspecified * make #cmakedefine output match autoconf when undefined * document cmake remove -f * document order of -D and -P * add support for DragonFly and GNU hurd * fix for fortran depends doing too many scans ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 4
A co-worker sees it on his Windows box (VS 7.1), but I don't on mine (VS 8). So I don't know how to trigger it on Windows. But I see it consistent for me on Linux, both with that simple example and ParaView. Of course, I don't see the msvcrt(d) link warnings. Clint On Tuesday 11 December 2007 1:53:36 pm David Cole wrote: It's something more than just this simple example... I've tried it with CMake 2.4.5, 2.4.7 and today's CVS CMake and it does not happen on my machine. (The Debug C always properly links to Ad only, not also to A...) I am using VS 2005 standard edition. The problem was occurring on the ParaView3 dashboards (until I masked it out by mucking with CXX_FLAGS last Friday) on morva and minastirith dashboards. Here's an example: http://www.paraview.org/ParaView3/Testing/Sites/morva.kitware/Win32-vs8/200 71207-0100-Nightly/BuildWarning.html morva is using CMake 2.4.5 and VS8 Professional edition, minastirith is using CMake 2.4.7 and VS8 Standard edition. Any other clues about what additional steps / settings might be required to trigger this error condition? On 12/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Can this be fixed for 2.4.8? It looks like it was already fixed for 2.6, but I couldn't find a bug report for it. = ADD_LIBRARY(A a.c) ADD_LIBRARY(Ad a.c) ADD_LIBRARY(B b.c) TARGET_LINK_LIBRARIES(B debug Ad optimized A) # if building shared libs, cmake correctly links B with -lAd OR -lA ADD_EXECUTABLE(C c.c) TARGET_LINK_LIBRARIES(C B) # cmake incorrectly links C with -lB -lAd -lA if build type is Debug === Clint On Wednesday 05 December 2007 3:13:39 pm Bill Hoffman wrote: I have a beta release for 2.4.8 ready for cmake. This will be the last release of the 2.4.X branch. The next release will be 2.6.0. So, please make sure you test it if you are interested in a 2.4.8. Send any issues to me or the cmake list. Thanks. The files can be found here: http://www.cmake.org/files/v2.4/*RC-4* The changes from 2.4.7 are as follows: Changes in CMake 2.4.8 RC 4 * fix for cpack and messing up PATH with NSIS Changes in CMake 2.4.8 RC 3 * fix for bug 5363: GET_TARGET_PROPERTY(... DEBUG_LOCATION) returns value containing $(OutDir) * Better error from ctest if nightly time not set * Fix for exception handling flags in VS 2003 and up * Avoid relinking exclude-from-all directory targets before install Changes in CMake 2.4.8 RC 2 * fix for bug 5590 relative paths in windows not working across drives * fix warning/error with TAR_VERBOSE flag Changes in CMake 2.4.8 RC 1 * Fix for kde4-config location * Fix for self extracting .sh files on solaris * Remove KDE3_ENABLE_FINAL (did not work) * KDE3 fix for 64 bit location of plugins * mark PYTHON_EXECUTABLE as advanced * Fix for version numbers on NetBSD * Add more search directories (install prefix and cmake location) * include WindowsPaths in Windows.cmake not just Windows-cl.cmake * documentation fix for file, find_package, try_run * add IS_ABSOLUTE to if * INSTALL() everything which doesn't have a COMPONENT set, is assigned to the COMPONENT Unspecified * make #cmakedefine output match autoconf when undefined * document cmake remove -f * document order of -D and -P * add support for DragonFly and GNU hurd * fix for fortran depends doing too many scans ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Swig dependencies not being tested?
Tristan, I have been slow to respond to your e-mail because it took a long
time to investigate the java problems created by your patch. Details,
below.
On 2007-12-11 10:59+0100 Tristan Carel wrote:
On Dec 10, 2007 8:58 PM, Alan W. Irwin [EMAIL PROTECTED] wrote:
Tristan, since you do not encounter this problem, are you doing something
qualitatively different than above in your CMakeLists.txt file?
I use `UseSWIG' the same way you do (except the unecessary `-python'
in CMAKE_SWIG_FLAGS, already added by the module when you specify the
target language in SWIG_ADD_MODULE macro). `UseSWIG.cmake' intends to
be smart and takes cares of *all* files generated by swig: not only
c/c++ code, but also wrappers in target language.
Thanks for that tip. That line now reads
set(CMAKE_SWIG_FLAGS -DPL_DOUBLE -DSWIG_PYTHON)
UseSwig.cmake uses basename of swig file to determine target language files.
So, do you have %module plplotcmodule or %module plpotc in the plplotcmodule.i?
The first line of plplotcmodule.i is
%module plplotc
This constraint on the filename can be quite inconvenient, furthermore
this does not work with Java wrappers :)
so here is a patch:
[...]
N.B. that patch did not work at all unless I changed
@@ -48,9 +49,15 @@
to
@@ -48,9 +49,14 @@
Anyhow, I am now using your patched version of UseSWIG.cmake
So in case the module name is different than the file's basename, you
can add a property SWIG_MODULE_NAME to swig files provided to the
`SWIG_ADD_MODULE' macro in order to force the module name defined by
these files:
SET_SOURCE_FILES_PROPERTIES(callback.i PROPERTIES SWIG_MODULE_NAME Callbacks)
# [...]
SWIG_ADD_MODULE(callback_module python callback.i ...)
Although it appears to be redundant since %module plplotc is specified in
plplotcmodules.i, I added the following line to the CMake code
set_source_files_properties(plplotcmodule.i
PROPERTIES SWIG_MODULE_NAME plplotc
)
I would be glad to know if it resolves your dependencies problem.
Yes, it does for the python case, but can you explain why this patched
version work (no gratuitous rebuilds) when %module plplotc alone does not
work with the unpatched version?
The remainder of this e-mail concerns the java compilation problems that
showed up with your patched version of UseSwig.cmake.
Your current approach for compiling java files does not work since there is
a whole boatload of *.java files generated by swig as well as some special
files which we need to compile as well. For the PLplot case the complete
list of java files (all but those marked as hand-crafted or configured are
generated by swig) is the following:
bindings/java/PLStream.java (hand-crafted)
in the source tree and
bindings/java/PLGraphicsIn.java
bindings/java/plplotjavac.java
bindings/java/plplotjavacConstants.java
bindings/java/plplotjavacJNI.java
bindings/java/config.java (configured)
in the build tree.
The plplotjavacConstants.java file can be taken care of by making the
following change to your patched UseSWIG.cmake:
-SET(SWIG_JAVA_EXTRA_FILE_EXTENSION JNI.java .java)
+# Order is important
+SET(SWIG_JAVA_EXTRA_FILE_EXTENSION JNI.java Constants.java .java)
Also, when compiling plplotjavacConstants.java, the results of
the plplotjavacJNI.java compilation cannot be found unless you
add
${CMAKE_BINARY_DIR}/CMakeFiles/plplotjavac_wrap.dir
to the list of directories referenced by INCLUDE_DIRECTORIES. There is no
guarantee in the future that this directory prefix will continue to be used
to store the class files so this change must be classified as a temporary
workaround. See below for a better approach which controls the location
where the class files are located.
Additionally, there is the showstopper problem of the swig-generated file
PLGraphicsIn.java. I only have a superficial knowledge of swig and java,
but I believe that file is generated because our API *.i file has a struct
defined that is called PLGraphicsIn. Anyhow, it appears in the Java case
that swig-generated files will have a variety of names depending on the *.i
internals of each separate project.
Furthermore, there is the showstopper issue of the PLplot-specific java file
called PLStream.java in the source tree, and our configured java file called
config.java in the build tree which also must be compiled in the right
order.
Finally, the patched UseSWIG.cmake approach generates the following cmake.out
error message.
-- Configuring done
CMake Error: Error required internal CMake variable not set, cmake may be
not be built correctly.
Missing variable is:
CMAKE_Java_CREATE_SHARED_MODULE
-- Generating done
-- Build files have been written to: /home/software/plplot_cvs/HEAD/build_dir
That error message makes no sense since java file compilation generates
class files and not shared modules or libraries. Anyhow, since the rest of
the message looks like everything worked, I believe that error message is
spurious. When I continued on with showstopper make after that the
[CMake] turning off compile testing
Is there any way to turn off try compile during configuration? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
