[CMake] parallel ctest
Does CTest support running multiple tests concurrently? So that one could run tests in a fraction of the time on an smp or dual-core system? For a project, we have a unix test script which does that, and I was wondering if CTest had that ( ... thinking of using CTest instead, as we're already using CMake ...). Thanks, Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] parallel ctest
Hi Clint, This feature is on my list, but it will probably take some time to develop it. So, the answer is: currently not. Andy Clinton Stimpson wrote: Does CTest support running multiple tests concurrently? So that one could run tests in a fraction of the time on an smp or dual-core system? For a project, we have a unix test script which does that, and I was wondering if CTest had that ( ... thinking of using CTest instead, as we're already using CMake ...). Thanks, Clint ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Andy Cedilnik Kitware Inc. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Xcode generator problems
Hi,
I just tried to generate Xcode project files for some of my
cmake supported sources. I encountered three problems:
1) I tried to communicate -framework Carbon flags
to the link stage. I tried
SET(LINK_FRAMEWORKS -framework Accelerate -framework Carbon)
SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE ${CMAKE_SHARED_LINKER_FLAGS_RELEASE}
${LINK_FRAMEWORKS} CACHE STRING Linker flags FORCE)
SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE ${CMAKE_SHARED_LINKER_FLAGS_RELEASE}
${LINK_FRAMEWORKS} CACHE STRING Linker flags FORCE)
as well as
SET_TARGET_PROPERTIES(svpmain${DEBUGEXT} PROPERTIES LINKER_LANGUAGE CXX
OUTPUT_NAME svp LINK_FLAGS ${LINK_FRAMEWORKS})
In both cases the generated project does not use the framework flags I asked
for. The unix makefile generator, however, works properly. Maybe there is a
reason or another mechanism that should be used?
The second problem is more annoying:
From time to time the compiler fails completely and the error.log shows the
error message:
...
setenv VERSION_INFO_STRING \@(#)PROGRAM:XCODE_DEPEND_HELPER PROJECT:CMAK
E_TRY_COMPILE- DEVELOPER:roebel BUILT:\ __DATE__ \ \ __TIME__ \\
setenv WARNING_CFLAGS -Wmost -Wno-four-char-constants
-Wno-unknown-pragmas
setenv XCODE_APP_SUPPORT_DIR /Library/Application Support/Apple/Developer
Tools
setenv YACC /usr/bin/yacc
/bin/sh
-c /Users/roebel/tmp/svp_basic_transformer/build/CMakeTmp/./CMAKE_T
RY_COMPILE.build/Debug/XCODE_DEPEND_HELPER.build/Script-6859806859806859800
0.sh
/bin/sh: /Users/roebel/tmp/svp_basic_transformer/build/CMakeTmp/./CMAKE_TRY_COM
PILE.build/Debug/XCODE_DEPEND_HELPER.build/Script-68598068598068598000.sh:
/bin/sh: bad interpreter: Text file busy
** BUILD FAILED **
All configuration tests therefore have more or less random values, because
they fail either due to the fact that the tested condition is false or because
the compiler fails completely. The systems I am working with are dual
processor machines and I suppose that has something to do with these errors.
cmake is version 2.2.3. Are there any known solutions?
The third problem is probably my missing understanding. I wanted to
overwrite the configuration types, however,
SET(CMAKE_CONFIGURATION_TYPES Release;Debug CACHE STRING Configuration
types FORCE)
did not change the value of CMAKE_CONFIGURATION_TYPES .
Is this variable read only?
Cheers,
--
Axel Roebel
IRCAM Analysis/Synthesis Team
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode generator problems
At 03:12 PM 5/1/2006, Axel Roebel wrote:
Hi,
I just tried to generate Xcode project files for some of my
cmake supported sources. I encountered three problems:
1) I tried to communicate -framework Carbon flags
to the link stage. I tried
SET(LINK_FRAMEWORKS -framework Accelerate -framework Carbon)
SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE ${CMAKE_SHARED_LINKER_FLAGS_RELEASE}
${LINK_FRAMEWORKS} CACHE STRING Linker flags FORCE)
SET(CMAKE_SHARED_LINKER_FLAGS_RELEASE ${CMAKE_SHARED_LINKER_FLAGS_RELEASE}
${LINK_FRAMEWORKS} CACHE STRING Linker flags FORCE)
as well as
SET_TARGET_PROPERTIES(svpmain${DEBUGEXT} PROPERTIES LINKER_LANGUAGE CXX
OUTPUT_NAME svp LINK_FLAGS ${LINK_FRAMEWORKS})
In both cases the generated project does not use the framework flags I asked
for. The unix makefile generator, however, works properly. Maybe there is a
reason or another mechanism that should be used?
-framework should be treated just like linking a library.
TARGET_LINK_LIBRARIES(foo -framework Bar)
In addition, for 2.4.1, if you give the full path to a framework,
CMake will automatically add the correct -F -framework flags.
The second problem is more annoying:
From time to time the compiler fails completely and the error.log shows the
error message:
...
setenv VERSION_INFO_STRING \@(#)PROGRAM:XCODE_DEPEND_HELPER PROJECT:CMAK
E_TRY_COMPILE- DEVELOPER:roebel BUILT:\ __DATE__ \ \ __TIME__ \\
setenv WARNING_CFLAGS -Wmost -Wno-four-char-constants
-Wno-unknown-pragmas
setenv XCODE_APP_SUPPORT_DIR /Library/Application Support/Apple/Developer
Tools
setenv YACC /usr/bin/yacc
/bin/sh
-c /Users/roebel/tmp/svp_basic_transformer/build/CMakeTmp/./CMAKE_T
RY_COMPILE.build/Debug/XCODE_DEPEND_HELPER.build/Script-6859806859806859800
0.sh
/bin/sh: /Users/roebel/tmp/svp_basic_transformer/build/CMakeTmp/./CMAKE_TRY_COM
PILE.build/Debug/XCODE_DEPEND_HELPER.build/Script-68598068598068598000.sh:
/bin/sh: bad interpreter: Text file busy
** BUILD FAILED **
All configuration tests therefore have more or less random values, because
they fail either due to the fact that the tested condition is false or because
the compiler fails completely. The systems I am working with are dual
processor machines and I suppose that has something to do with these errors.
cmake is version 2.2.3. Are there any known solutions?
This is a bug in xcodebuild. CMake 2.4.1 contains a work around. There
is a program called cmakexbuild that will forward to xcodebuild, and if
it sees text file busy, it will re-run the build. CMake 2.4.1 uses
this for try-compile tests and ctest builds so that things are more predicable.
The third problem is probably my missing understanding. I wanted to
overwrite the configuration types, however,
SET(CMAKE_CONFIGURATION_TYPES Release;Debug CACHE STRING Configuration
types FORCE)
Try this in 2.4.1.
did not change the value of CMAKE_CONFIGURATION_TYPES .
Is this variable read only?
No, that should work.
In summary, give 2.4.1 a try and get back with any other problems.
There was a lot of work done for Xcode in 2.4.
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Xcode generator problems
On Tuesday 02 May 2006 03:43, William A. Hoffman wrote: At 08:09 PM 5/1/2006, Axel Roebel wrote: Hello William, god news that there is a new version. I tried it instantly. My first impression was not so positive I found that it takes ages for the dependency checking. I am working with template libraries where most of the code is in include files. May be it is due to that, but with cmake 2.2.3 dependency checking was nevertheless 10 times faster. With 2.4.1 dependency checking takes longer than compiling the project. I don't think any changes were made in that area. In fact, if anything it should be faster. Did you build cmake with the same compiler/flags for 2.2.3 and 2.4.1? Also, I assume this is the not Xcode generator because that one does not do dependency checks in CMake. Yes, I started to try unix makefiles, because I use them most of the time. The other problem I had with 2.2.3 was that on macosx the shared libraries that I linked with were searched in the build directories not in the install directories. That seems to be fixed in 2.4.1. However, dependency checking is much longer. I did a direct comparison: with cmake 2.2.3 compiled with the default type , I suppose this none time /u/formes/share/bin/cmake -E cmake_depends Unix Makefiles /Users/roebel/src/svp/build241 /Users/roebel/src/svp/build241/compile/KernelBuild /Users/roebel/src/svp/build241/compile/KernelBuild/CMakeFiles/svp_kernel.dir/DependInfo.cmakereal real0m15.032s user0m10.154s sys 0m4.593s with 2.4.1 compiled with type release ( which did not improve compared to none) time /Users/roebel/src/cmake-2.4.1/bin/cmake -E cmake_depends Unix Makefiles /Users/roebel/src/svp/build241 /Users/roebel/src/svp/build241/compile/KernelBuild /Users/roebel/src/svp/build241/compile/KernelBuild/CMakeFiles/svp_kernel.dir/DependInfo.cmake real2m5.792s user0m7.613s sys 1m56.915s This is nearly 10 times longer Interestingly the user processing time is faster, however, system time has excessively increased. Note, that this has been measured on the same system which was doing nothing else but the dependency check! By the way, another problem with 2.4.1 is that the OUTPUT_NAME of SET_TARGET_PROPERTIES is no longer working (at least for unix makefiles) -- Axel Roebel IRCAM Analysis/Synthesis Team ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
