Re: [CMake] CTest examples
Den 10-07-2010 00:05, David Cole skrev: On Fri, Jul 9, 2010 at 5:54 PM, Chris Hillery chillery-cm...@lambda.nu mailto:chillery-cm...@lambda.nu wrote: [...] On Fri, Jul 9, 2010 at 4:37 AM, Bo Thorsen b...@askmonty.org mailto:b...@askmonty.org wrote: [...] To sum it up, I'm looking for real life advice on what you guys have done with ctest. This information seem almost completely missing on the net, where all searches on ctest leads to useless presentation on ctest features. Nice analysis! Thanks for taking the time to write this up and send it along to the mailing list. I agree. This was exactly what I asked for. Thanks a lot. Bo Thorsen. Monty Program AB. -- MariaDB: MySQL replacement Community developed. Feature enhanced. Backward compatible. ___ 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] CTest examples
Den 09-07-2010 19:03, Eric Noulard skrev: 2010/7/9 Bo Thorsenb...@askmonty.org: Hi people, I have converted a set of applications to cmake and cpack, and now have my eyes set on ctest. I'd like to hear if someone here has some good advice, or links to good advice, on how to structure tests. I'm searching for help on how to put different tests into what executables. On how to handle multiple tests on each classes, on how to best structure the test of the static libraries (all of those are part of the source tree) that are linked in to the application. And on how to test classes from the main application itself. I have read the ctest FAQ, documentation etc. and still don't know anything that help me write the actual test code. From the looks of it, ctest only provides the framework to run a test, no help is given to write the code of the tests themselves, is this right? I have previously been using cppunit, and it looks like this will still be useful. Yes you are right. CTest is helping for running tests using Test Driver. CTest is useful for continuous integration if you use it with CDash and for that part (from my point of view) it's useful if do not have test at all, because you may monitor build breakage on various platform. It helps even more if the tests application (which may be written using cppunit) is built using CMake and/or is linked with the library your are building (with CMake ...) in an add_test(NAME TestName COMMAND TestProg) TestProg (the Test Driver) may be built from an add_executable(TestProg TestProg.c) target_link_libraries(TestProg TheTestedLib) or it may be a custom script (Python or anything you like) or it may be a custom script which has been configured at CMake time using configure_file To sum it up, I'm looking for real life advice on what you guys have done with ctest. This information seem almost completely missing on the net, where all searches on ctest leads to useless presentation on ctest features. Real life usually depends on your life but... Speaking for myself on two small projects (C and/or C++) I do use simple (C or C++) test driver applications for basic unit test and some python scripts for integration tests. My [compiled C/C++] test drivers simply return 0 if the test is successfull and something else if not. CTest understand that out-of-the-box which makes it easy to see unit test breakage using a simple make test. My Python script is driving several interacting applications (from 2 up to 10) which are part of the build, in the same way the python script return non zero value on error. Since the whole testsuite may be running for a long time I'm using CTest during development in order to easily select test to be run on a particular area using ctest -Rregex = Run tests matching regular expression. I have my own naming rules for tests name which makes it easy to use. I'm not using any unit test framework but I think there has already been some discussion about mixed CMake/CTest CppUnit usage on this list. Now I really cannot ensure that those advices will be as good for you as they are too me :-) It is certainly helpful. And together with Davids reply, I have a good clear picture of CTest. It matches what I had come up with myself, but it's good to know I hadn't missed some opportunity. Thanks for you help. Bo Thorsen. Monty Program AB. -- MariaDB: MySQL replacement Community developed. Feature enhanced. Backward compatible. ___ 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
[CMake] incremental build slow because of F90 (cmake_copy_f90_mod)
Hi, We're finding incremental builds to be slow, because the F90 source seems to be privy to a processing step known as cmake_copy_f90_mod. While cmake and the compiler race through C/CXX/Fortran(77) source, this is not the case for F90. What does cmake_copy_f90_mod do? I can hardly find any documentation for it :) Are there workarounds that may decrease time spent in this area during incremental compiles? Thanks, Arjen Arjen Verweij QA/Test Engineer [cid:image001.gif@01CB21C7.4E698DA0] Einsteinlaan 6 2289 CC Rijswijk The Netherlands Phone: +31 88 827 7086 Fax: +31 88 827 7003 Email: arjen.verw...@tass-safe.com www.tass-safe.com This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS. inline: image001.gif___ 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
[CMake] calling c-compiler by hand
Hi!
I'd like to call the c-compiler by hand as pre-link step to compile in
the current svn version.
on windows i first separate the arguments
separate_arguments(CFLAGS WINDOWS_COMMAND ${CMAKE_CXX_FLAGS}
${CMAKE_CXX_FLAGS_DEBUG} /c)
and then I do
add_custom_command(TARGET MyProject PRE_LINK
COMMAND ${CMAKE_CXX_COMPILER} ${CFLAGS}
${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
VERBATIM
)
Now the problem: currently CMAKE_CXX_FLAGS_DEBUG is hard-coded. how can
i substitute it
with the current configuration? If it is release then the contents of
CMAKE_CXX_FLAGS_RELEASE should
be taken.
-Jochen
___
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] Quieting/speeding output
Perhaps I should clarify I bit. It seems my subject line conflated the two distinct (but tangentially related) issues (perhaps it should have been two different emails). The subject line I should have used was something like quieting output / speeding builds Yes, I agree that the number of times make is called is a big part of the slowdown, is there any way to reduce this overhead? I suspect reducing this overhead is extremely non-trivial. I still would like a way to quiet down the output. I am getting close to writing a wrapper for cmake that will filter the output, and perhaps simplify the inputs a little (or at least make them closer to what most of my devs are using right now to ease the transition) Kevin On Sun, Jul 11, 2010 at 1:55 PM, J Decker d3c...@gmail.com wrote: Actually if you run it with make VERBOSE=1 you'll see that make is invoked a TON of times... each target is a seperate invokation of make, including using make to validate the cmake files are built... it's not really the output but the huge amount of times that make is run. On Sun, Jul 11, 2010 at 8:40 AM, Kevin Fitch kfitc...@gmail.com wrote: I am transitioning from a make based build system to cmake, overall I am quite happy with cmake, but currently there are two snags: 1) The main project I am doing this on is quite large, it produces about 300 targets. So, when I type 'make' I get 300 or so lines of [ 27%] Built target blah... even when there is nothing (or very little) to do. This is quite annoying. I tried messing with CMAKE_RULE_MESSAGES. I just added -DCMAKE_RULE_MESSAGES=OFF to the cmake invocation. But that didn't seem to help. 2) The follow on to this is that a 'do-nothing' build still takes about 4 seconds (or about 1.25 seconds for make -j. The previous make based build was effectively instantaneous for a 'do-nothing' build. The do-nothing (or do very little) build is the common case so I hate to regress that far. Where should I be looking to address these issues? I suspect (2) is a result of cmake generating a recursive make system (as opposed to the current make based system we have that uses recursive includes, instead of recursive make calls). Kevin ___ 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 ___ 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] option bug ?
On 07/07/2010 09:44 AM, Michael Wild wrote:
On 7. Jul, 2010, at 9:32 , Michael Hertling wrote:
On 07/03/2010 01:03 AM, Chris Hillery wrote:
There's a slightly nicer work-around: Change project A's CMakeLists to set
PROJB_OPENCV_LINK as a cache variable, ie, SET(PROJB_OPENCV_LINK NO CACHE
BOOLEAN doc). I've tested it locally and it works the way you want it to.
It seems that CMake divides the world of variables into two classes: cache
variables and non-cache variables. Somewhat unfortunately, the same
function, SET(), is used to specify values for both kinds, and cache
variables hide any non-cache variables with the same name. The upshot is
that the same SET() command will do different things depending on what's
currently in the cache.
Further confusion here comes from the fact that when a variable is declared
as a cache variable (using either option() or set(...CACHE...) ), any
current value that the non-cache variable with the same name has is
discarded. So the first time you run cmake, PROJB_OPENCV_LINK isn't a cache
variable until it gets to processing projb's CMakeLists.txt, hence the
non-cache value you provided gets dropped. The second time, it's already a
cache variable, so project A's CMakeLists actually sets the cache variable,
and therefore projb's CMakeLists sees it as you expect.
It's definitely confusing, but I'm not totally sure what the right solution
is. It probably would have been cleaner if CMake made the distinction clear
between cache and non-cache variables, but it's far too late to change that
now. Maybe it would be possible to change it such that a cache variable
declaration (option() or set(...CACHE...) ) would allow a current non-cache
variable of the same name to override the declaration's default value, in
the same way that -D on the command-line does.
IMO, things aren't sooo bad. ;-)
W.r.t. the value of a variable, CMake knows scopes and the cache. A new
scope is entered by ADD_SUBDIRECTORY() or a function's invocation. When
referring to a variable's value by the ${} operator you get the value
from the current scope. At the start of a CMake run, the variables are
initialized with the values from the cache, provided the latter exists
and is appropriately populated. The SET() command - that is the actual
source of confusion along with OPTION() - basically has four flavours:
(1) SET(VAR xyz) sets the value of VAR in the current scope to xyz,
i.e. ${VAR} yields xyz until the value of VAR is changed anew.
(2) SET(VAR xyz PARENT_SCOPE) sets the value of VAR in the parent's
scope to xyz, but doesn't affect the current scope or the cache.
(3) SET(VAR xyz CACHE STRING ... FORCE) sets VAR's value in the
current scope and in the cache to xyz regardless if there's
already a cached value or VAR is defined in the current scope.
(4) SET(VAR xyz CACHE STRING ...) sets VAR's value in the cache
to xyz unless there's already a cached value for VAR, and the
latter's value in the current scope is set from the cache if
(a) the SET() writes to the cache, or
(b) VAR is undefined in the current scope, or
(c) the type of VAR in the cache is UNINITIALIZED.
While (4a,b) are quite reasonable, (4c) is somewhat strange as it
yields different results for apparently equivalent invocations:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(VARS NONE)
MESSAGE(VAR{1,2}[CACHE]: ${VAR1},${VAR2})
SET(VAR1 abc)
SET(VAR2 abc)
MESSAGE(VAR{1,2}[LOCAL]: ${VAR1},${VAR2})
UNSET(VAR2)
SET(VAR1 xyz CACHE STRING )
SET(VAR2 xyz CACHE STRING )
MESSAGE(VAR{1,2}[FINAL]: ${VAR1},${VAR2})
Cmaking from a clean build directory yields, as expected, (4a):
VAR{1,2}[CACHE]: ,
VAR{1,2}[LOCAL]: abc,abc
VAR{1,2}[FINAL]: xyz,xyz
Afterwards, cmake -DVAR1:STRING=pqr -DVAR2:STRING=pqr . yields:
VAR{1,2}[CACHE]: pqr,pqr
VAR{1,2}[LOCAL]: abc,abc
VAR{1,2}[FINAL]: abc,pqr
So, VAR1 is finally not set from the cache, but VAR2 is as it's
undefined in the current scope at that moment; this proves (4b).
Now, cmake -DVAR1=pqr -DVAR2=pqr . reveals (4c):
VAR{1,2}[CACHE]: pqr,pqr
VAR{1,2}[LOCAL]: abc,abc
VAR{1,2}[FINAL]: pqr,pqr
The parameter -DVAR1=pqr, i.e. without a type, supplies the cache
with VAR1:UNINITIALIZED=pqr for VAR1, and the subsequent command
SET(VAR1 xyz CACHE STRING ) changes VAR1's type to STRING, but
does not touch the cached value; though, the latter is written to
VAR1 in the current scope. Here, I'm in doubt if this behaviour is
really intended.
To summarize: If none of (4a-c) holds, i.e. an already cached value
for VAR with a type other than UNINITIALIZED and VAR defined in the
current scope, SET(VAR xyz CACHE STRING ...) just does nothing.
It's that (4a-c) which causes the confusion in regard to a variable's
value in the cache and the current scope, and as OPTION(VAR ... ON)
is, AFAIK, quite the same as SET(VAR ON CACHE BOOL ...), the above-
mentioned considerations apply accordingly. So, the
Re: [CMake] calling c-compiler by hand
On 07/12/2010 04:14 PM, Jochen Wilhelmy wrote:
Hi!
I'd like to call the c-compiler by hand as pre-link step to compile in
the current svn version.
on windows i first separate the arguments
separate_arguments(CFLAGS WINDOWS_COMMAND ${CMAKE_CXX_FLAGS}
${CMAKE_CXX_FLAGS_DEBUG} /c)
and then I do
add_custom_command(TARGET MyProject PRE_LINK
COMMAND ${CMAKE_CXX_COMPILER} ${CFLAGS}
${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
VERBATIM
)
Why don't you simply mention ${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
with your target's source files? IMO, tampering with the compiler flags
in order to incorporate version information is not the right approach.
Regards,
Michael
Now the problem: currently CMAKE_CXX_FLAGS_DEBUG is hard-coded. how can
i substitute it
with the current configuration? If it is release then the contents of
CMAKE_CXX_FLAGS_RELEASE should
be taken.
-Jochen
___
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
[CMake] CMAKE_LANG_FLAGS added to link rule
Hi, It seems that in our project the contents of CMAKE_LANG_FLAGS is added to the link line. This causes problems for some of our platforms. Is there a mechanism to separate language specific compile and link flags out? It would be nice if you could define CMAKE_LANG_COMPILER_FLAGS and CMAKE_LANG_LINK_FLAGS separately. I could write a wrapper around add_executable() and add_library() but I would prefer something standard. Looking at cmake-2.8.1/Modules/CMakeFortranInformation.cmake, I can't really find much except that CMAKE_Fortran_LINK_EXECUTABLE is set, but CMAKE_Fortran_FLAGS are not included. Regards, Arjen Arjen Verweij QA/Test Engineer [cid:image001.gif@01CB21E8.0002BDA0] Einsteinlaan 6 2289 CC Rijswijk The Netherlands Phone: +31 88 827 7086 Fax: +31 88 827 7003 Email: arjen.verw...@tass-safe.com www.tass-safe.com This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS. inline: image001.gif___ 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
[CMake] calling c-compiler by hand
Hi!
adding
${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
to the source files does not have the desired effect.
If I change some file of the target, VersionInfo.cpp
does not get recompiled and therefore the current version
is not incorporated into the build.
Therefore I want to recompile it as pre-link step.
Any Ideas how to do it?
-Jochen
___
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] CMAKE_LANG_FLAGS added to link rule
As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include FLAGS gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful) stuff as well? As a sidetrack I'm starting to wonder what the purpose of CMAKE_LANG_FLAGS is. The book lists it as cmake's counterpart of the environment variable, e.g. CMAKE_CXX_FLAGS and CXXFLAGS from the shell, which means it doesn't make sense to include it when linking. Am I overlooking something here :) Regards, Arjen From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: maandag 12 juli 2010 18:13 To: cmake@cmake.org Subject: [CMake] CMAKE_LANG_FLAGS added to link rule Hi, It seems that in our project the contents of CMAKE_LANG_FLAGS is added to the link line. This causes problems for some of our platforms. Is there a mechanism to separate language specific compile and link flags out? It would be nice if you could define CMAKE_LANG_COMPILER_FLAGS and CMAKE_LANG_LINK_FLAGS separately. I could write a wrapper around add_executable() and add_library() but I would prefer something standard. Looking at cmake-2.8.1/Modules/CMakeFortranInformation.cmake, I can't really find much except that CMAKE_Fortran_LINK_EXECUTABLE is set, but CMAKE_Fortran_FLAGS are not included. Regards, Arjen Arjen Verweij QA/Test Engineer [cid:image001.gif@01CB21F5.056CED80] Einsteinlaan 6 2289 CC Rijswijk The Netherlands Phone: +31 88 827 7086 Fax: +31 88 827 7003 Email: arjen.verw...@tass-safe.com www.tass-safe.com This e-mail and its contents are subject to a DISCLAIMER with important RESERVATIONS. inline: image001.gif___ 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] incremental build slow because of F90 (cmake_copy_f90_mod)
On 07/12/2010 07:51 AM, Verweij, Arjen wrote: We’re finding incremental builds to be slow, because the F90 source seems to be privy to a processing step known as “cmake_copy_f90_mod”. While cmake and the compiler race through C/CXX/Fortran(77) source, this is not the case for F90. What does “cmake_copy_f90_mod” do? I can hardly find any documentation for it J Are there workarounds that may decrease time spent in this area during incremental compiles? Actually the copy-f90-mod step is a *feature* to make incremental rebuilds faster. It is an optimization for the case that the .f90 source file that provides a module gets recompiled but the *interface* to the module does not change. Many compilers update the timestamp on the .mod file anyway. In this case we do not want all the sources that use the module to recompile needlessly. The copy-f90-mod step copies the .mod file to a module timestamp file in a way that does not modify the timestamp unless the module really changed. -Brad ___ 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] CMAKE_LANG_FLAGS added to link rule
On 07/12/2010 01:12 PM, Verweij, Arjen wrote: As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include FLAGS gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful) stuff as well? As a sidetrack I’m starting to wonder what the purpose of CMAKE_LANG_FLAGS is. The book lists it as cmake’s counterpart of the environment variable, e.g. CMAKE_CXX_FLAGS and CXXFLAGS from the shell, which means it doesn’t make sense to include it when linking. Am I overlooking something here J AFAIK no one designed it this way, it just happened over time during development. My guess is that people wanted compile flags like -m64 to be passed when the compiler is used as a front-end to the linker. Since it's been in the default rules for years we cannot change it without breaking compatibility. All of this was developed before CMake supported Fortran. I've seen very few C and C++ compilers that do not accept/ignore all of their compiler flags even when used as a linking front-end. That's likely why this wasn't caught at the beginning. -Brad ___ 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] incremental build slow because of F90 (cmake_copy_f90_mod)
Hi Brad, Actually the copy-f90-mod step is a *feature* to make incremental rebuilds faster. It is an optimization for the case that the .f90 source file that provides a module gets recompiled but the *interface* to the module does not change. Many compilers update the timestamp on the .mod file anyway. In this case we do not want all the sources that use the module to recompile needlessly. The copy-f90-mod step copies the .mod file to a module timestamp file in a way that does not modify the timestamp unless the module really changed. Cmake_copy_f90_mod gets called every time I type make for (as far as I can tell) every F90 file that provides a module. So for instance I change a comment in my main.f, the compile and linktime for the executable (4000 ish files) NOT including the time spent in the F90 portion of the tree is 5 seconds, but the F90 part takes a minute. I don't see any recompiling going on for the F90 part. Does cmake_copy_f90_mod get called even if you don't have to compile any F90 files? Thanks, Arjen ___ 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] CMAKE_LANG_FLAGS added to link rule
Brad, Can you comment on what other stuff ends up in FLAGS? If it's just CMAKE_LANG_FLAGS, I guess redefining CMAKE_LANG_LINK_EXECUTABLE would be a viable workaround. Thanks, Arjen -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: maandag 12 juli 2010 19:20 To: Verweij, Arjen Cc: cmake@cmake.org Subject: Re: [CMake] CMAKE_LANG_FLAGS added to link rule On 07/12/2010 01:12 PM, Verweij, Arjen wrote: As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include FLAGS gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful) stuff as well? As a sidetrack I'm starting to wonder what the purpose of CMAKE_LANG_FLAGS is. The book lists it as cmake's counterpart of the environment variable, e.g. CMAKE_CXX_FLAGS and CXXFLAGS from the shell, which means it doesn't make sense to include it when linking. Am I overlooking something here J AFAIK no one designed it this way, it just happened over time during development. My guess is that people wanted compile flags like -m64 to be passed when the compiler is used as a front-end to the linker. Since it's been in the default rules for years we cannot change it without breaking compatibility. All of this was developed before CMake supported Fortran. I've seen very few C and C++ compilers that do not accept/ignore all of their compiler flags even when used as a linking front-end. That's likely why this wasn't caught at the beginning. -Brad ___ 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] CMAKE_LANG_FLAGS added to link rule
On 7/12/2010 1:20 PM, Brad King wrote: On 07/12/2010 01:12 PM, Verweij, Arjen wrote: As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include FLAGS gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful) stuff as well? As a sidetrack I’m starting to wonder what the purpose of CMAKE_LANG_FLAGS is. The book lists it as cmake’s counterpart of the environment variable, e.g. CMAKE_CXX_FLAGS and CXXFLAGS from the shell, which means it doesn’t make sense to include it when linking. Am I overlooking something here J AFAIK no one designed it this way, it just happened over time during development. My guess is that people wanted compile flags like -m64 to be passed when the compiler is used as a front-end to the linker. Since it's been in the default rules for years we cannot change it without breaking compatibility. All of this was developed before CMake supported Fortran. I've seen very few C and C++ compilers that do not accept/ignore all of their compiler flags even when used as a linking front-end. That's likely why this wasn't caught at the beginning. It also came from template instantiating C++ compilers. They have a habit of compiling C++ code during the link, and if the flags are not there things did not compile. Also, some flags like -fPIC where needed with both. -Bill ___ 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] CMAKE_LANG_FLAGS added to link rule
On 07/12/2010 01:25 PM, Verweij, Arjen wrote: Can you comment on what other stuff ends up in FLAGS? Looking at the implementation I see it gets architecture flags on the Mac (-arch and -isysroot), which is consistent with the -m64 type flags I mentioned before. However it looks to me like things have been refactored enough to simply move these into the link-only flags with a one-line change. The change would not solve the original problem but would enable your workaround. Bill? -Brad diff --git a/Source/cmMakefileExecutableTargetGenerator.cxx b/Source/cmMakefileExecutableTargetGenerator.cxx index 93c981a..cb41e74 100644 --- a/Source/cmMakefileExecutableTargetGenerator.cxx +++ b/Source/cmMakefileExecutableTargetGenerator.cxx @@ -229,7 +229,7 @@ void cmMakefileExecutableTargetGenerator::WriteExecutableRule(bool relink) // Add language feature flags. this-AddFeatureFlags(flags, linkLanguage); - this-LocalGenerator-AddArchitectureFlags(flags, this-Target, + this-LocalGenerator-AddArchitectureFlags(linkFlags, this-Target, linkLanguage, this-ConfigName); // Add target-specific linker flags. ___ 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] incremental build slow because of F90 (cmake_copy_f90_mod)
On 07/12/2010 01:23 PM, Verweij, Arjen wrote: Cmake_copy_f90_mod gets called every time I type make for (as far as can tell) every F90 file that provides a module. So for instance I change a comment in my main.f, the compile and linktime for the executable (4000 ish files) NOT including the time spent in the F90 portion of the tree is 5 seconds, but the F90 part takes a minute. I don't see any recompiling going on for the F90 part. Does cmake_copy_f90_mod get called even if you don't have to compile any F90 files? It's not *supposed* to do that. Can you produce a minimal project that reproduces that behavior? -Brad ___ 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] calling c-compiler by hand
On 07/12/2010 07:06 PM, Jochen Wilhelmy wrote:
Hi!
adding
${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
to the source files does not have the desired effect.
If I change some file of the target, VersionInfo.cpp
does not get recompiled and therefore the current version
is not incorporated into the build.
Therefore I want to recompile it as pre-link step.
Any Ideas how to do it?
http://www.mail-archive.com/cmake@cmake.org/msg29944.html
It should be easy to replace Git by Subversion in the example.
Regards,
Michael
___
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] incremental build slow because of F90 (cmake_copy_f90_mod)
Hi Brad, It's not *supposed* to do that. Can you produce a minimal project that reproduces that behavior? This is reassuring. I'm probably not able to reproduce it with something small, but I could try. I would imagine that if it's not supposed to do it, it likely won't :) Apparently, the project has been set up in a peculiar way causing cmake to require touch cmake_copyf90_mod. The current build system has issues with this part of the code as well, with incremental builds. Thanks, Arjen ___ 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] calling c-compiler by hand
On 07/12/2010 08:24 PM, Michael Hertling wrote:
On 07/12/2010 07:06 PM, Jochen Wilhelmy wrote:
Hi!
adding
${CMAKE_CURRENT_SOURCE_DIR}/VersionInfo.cpp
to the source files does not have the desired effect.
If I change some file of the target, VersionInfo.cpp
does not get recompiled and therefore the current version
is not incorporated into the build.
Therefore I want to recompile it as pre-link step.
Any Ideas how to do it?
http://www.mail-archive.com/cmake@cmake.org/msg29944.html
As I've just seen, www.mail-archive.com modified the CMakeLists.txt
at a rather critical line; the unaltered version can be found here:
http://www.cmake.org/pipermail/cmake/2010-July/038015.html
Regards,
Michael
___
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] CMAKE_LANG_FLAGS added to link rule
Brad, That sounds fine, I'm already in the habit of specifying link flags per language anyway. In fact I will take a looksie and recompile cmake with your suggested fix. Regards, Arjen Looking at the implementation I see it gets architecture flags on the Mac (-arch and -isysroot), which is consistent with the -m64 type flags I mentioned before. However it looks to me like things have been refactored enough to simply move these into the link-only flags with a one-line change. The change would not solve the original problem but would enable your workaround. Bill? -Brad diff --git a/Source/cmMakefileExecutableTargetGenerator.cxx b/Source/cmMakefileExecutableTargetGenerator.cxx index 93c981a..cb41e74 100644 --- a/Source/cmMakefileExecutableTargetGenerator.cxx +++ b/Source/cmMakefileExecutableTargetGenerator.cxx @@ -229,7 +229,7 @@ void cmMakefileExecutableTargetGenerator::WriteExecutableRule(bool relink) // Add language feature flags. this-AddFeatureFlags(flags, linkLanguage); - this-LocalGenerator-AddArchitectureFlags(flags, this-Target, + this-LocalGenerator-AddArchitectureFlags(linkFlags, this-Target, linkLanguage, this- ConfigName); // Add target-specific linker flags. ___ 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] CTest examples
I'm been using Boost Test, and I've written a module that lets you add
the executable and the tests (where possible, individual named tests)
with a single command - see my github repositories for projects that
include this module. http://github.com/rpavlik
On 7/9/10 9:04 PM, Alok Govil wrote:
While I was suspecting something like this about CTest, your
explanation helps a lot.
I have integrated UnitTest++ into my flow, and it is working quite
well. It does also return a 0 if all tests pass, so one could
integrate with CTest/CDash if desirable.
Thanks
Date: Fri, 9 Jul 2010 14:54:46 -0700
From: chillery-cm...@lambda.nu
To: b...@askmonty.org
CC: cmake@cmake.org
Subject: Re: [CMake] CTest examples
For CTest, running a test means running an executable and seeing
whether the result of that process is 0 (success) or not 0 (failure).
It is also possible to scan the output of the executable for certain
regular expressions to determine success or failure.
It's a very simple and somewhat limited mechanism. It does depend on
you writing your own test driver, which makes sense because CMake
can't possibly know how to test your code.
As an example, Zorba is an XQuery (xml query language) processor. The
majority of our tests are actual XQueries stored in text files with
the extension .xq, along with corresponding expected results in .xml
files. We have a testdriver program which executes the query, checks
the results, and returns 0 or 1.
Our CMakeLists looks vaguely like this:
add_executable(testdriver ${TESTDRIVER_SRCS})
file(GLOB_RECURSE TESTFILES ${CMAKE_CURRENT_SOURCE_DIR} *.xq)
foreach(TESTFILE ${TESTFILES})
add_test(${TESTFILE} testdriver ${TESTFILE})
endforeach()
This creates one test for each .xq file. The name of the test is the
name of the .xq file, and that same name is passed as an argument to
testdriver.
This works well, and lets us use ctest's functionality like -R to run
certain tests by name. It also results in nice easy-to-read listings
on CDash because there's one line for each test, making it easy to
examine failures. (Although given that we have over 20,000 tests, some
pages on CDash take a long time to load...) The main downside is
speed, since every single test has to start up a whole Zorba process.
When you get to unit testing, however, IMHO things don't work as well.
CMake does offer the create_test_sourcelist() command, and you should
look into it. We use that in a couple places to create a single test
driver from several separate small unit test drivers. However, you
still need to write a loop in CMakeLists to add multiple tests using
that test driver.
In another project I work on, I've been using CxxTest for a unit
testing framework. This is a really nice setup as it makes it very
trivial to write many unit tests. However, the integration with ctest
is poor. There's a reasonably good FindCxxTest script shipped with
CMake that makes it easy to get CxxTest suites running; in a nutshell:
find_package(CxxTest)
cxx_add_test(my_unit_test my_unit_test.cpp
${CMAKE_CURRENT_SOURCE_DIR}/my_unit_test.h)
Unit tests in CxxTest are written as classes in a .h file;
cxx_add_test() runs CxxTest to generate the named .cpp file from that,
then builds it into the named test driver and adds a CTest test for
it. So far so good. However, the main benefit of CxxTest is grouping
similar test cases into a single .h file, probably with similar setup
and so forth. Unfortunately cxx_add_test() only adds one test to
CTest, and that one test runs all the test cases in the .h file. So
you lose the ability to run certain tests with ctest -R, and the
reports on CDash will just show whether ALL the tests in my_unit_test
succeeded or not.
The fundamental problem is that ctest requires a test case to be a
program execution, and has no facilities to allow a program to
represent multiple tests. So either you pay the cost in speed, or you
lose some of the flexibility ctest and cdash offer. (To be fair, even
if this were fixed in ctest, CxxTest would also need some
modifications as it currently doesn't let you run subsets of tests
either.)
Ceej
aka Chris Hillery
On Fri, Jul 9, 2010 at 4:37 AM, Bo Thorsen b...@askmonty.org
mailto:b...@askmonty.org wrote:
Hi people,
I have converted a set of applications to cmake and cpack, and now
have my eyes set on ctest.
I'd like to hear if someone here has some good advice, or links to
good advice, on how to structure tests. I'm searching for help on
how to put different tests into what executables. On how to handle
multiple tests on each classes, on how to best structure the test
of the static libraries (all of those are part of the source tree)
that are linked in to the application. And on how to test classes
from the main application itself.
I have read the ctest FAQ, documentation etc. and
Re: [CMake] CTest examples
From: cmake-boun...@cmake.org on behalf of Ryan Pavlik Sent: Mon 7/12/2010 9:59 AM To: cmake@cmake.org Subject: Re: [CMake] CTest examples I'm been using Boost Test, and I've written a module that lets you add the executable and the tests (where possible, individual named tests) with a single command - see my github repositories for projects that include this module. http://github.com/rpavlik What is the name of your module? Stephen Stephen Torri, PhD NAVAL SURFACE WARFARE CENTER DAHLGREN 17214 Ave B Suite 121 Dahlgren, Va. 22448 540-653-1082 I am not a contracting officer. I cannot modify or initiate contracts, nor do I have the authority to financially commit the government in any way. ___ 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] CMAKE_LANG_FLAGS added to link rule
Brad, That bit of code is #IFDEF'ed for __APPLE__. I doubt it is causing the problem on AIX. Regards, Arjen -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Verweij, Arjen Sent: maandag 12 juli 2010 20:47 To: Brad King Cc: cmake@cmake.org; Bill Hoffman Subject: Re: [CMake] CMAKE_LANG_FLAGS added to link rule Brad, That sounds fine, I'm already in the habit of specifying link flags per language anyway. In fact I will take a looksie and recompile cmake with your suggested fix. Regards, Arjen Looking at the implementation I see it gets architecture flags on the Mac (-arch and -isysroot), which is consistent with the -m64 type flags I mentioned before. However it looks to me like things have been refactored enough to simply move these into the link-only flags with a one-line change. The change would not solve the original problem but would enable your workaround. Bill? -Brad diff --git a/Source/cmMakefileExecutableTargetGenerator.cxx b/Source/cmMakefileExecutableTargetGenerator.cxx index 93c981a..cb41e74 100644 --- a/Source/cmMakefileExecutableTargetGenerator.cxx +++ b/Source/cmMakefileExecutableTargetGenerator.cxx @@ -229,7 +229,7 @@ void cmMakefileExecutableTargetGenerator::WriteExecutableRule(bool relink) // Add language feature flags. this-AddFeatureFlags(flags, linkLanguage); - this-LocalGenerator-AddArchitectureFlags(flags, this-Target, + this-LocalGenerator-AddArchitectureFlags(linkFlags, this-Target, linkLanguage, this- ConfigName); // Add target-specific linker flags. ___ 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 ___ 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] CMAKE_LANG_FLAGS added to link rule
On 07/12/2010 02:47 PM, Verweij, Arjen wrote: I will take a looksie and recompile cmake with your suggested fix. The patch was more of a starting point for discussion among developers. I think the same problem occurs for shared libraries too, but I see evidence that it was done on purpose: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f532f54 The commit message does not give a reason. Perhaps the mailing list archives from that time do. -Brad ___ 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] CMAKE_LANG_FLAGS added to link rule
On 07/12/2010 03:06 PM, Verweij, Arjen wrote: That bit of code is #IFDEF'ed for __APPLE__. I doubt it is causing the problem on AIX. That code is not the cause of the problem, just something that might be broken by your workaround to the problem. AFAIK there is nothing that will be broken on AIX by removing FLAGS from the link rule for Fortran executables. What flags are causing the problem? -Brad ___ 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] CTest examples
On 7/12/2010 2:00 PM, Torri, Stephen CIV NSWCDD, W15 wrote: From: cmake-boun...@cmake.org on behalf of Ryan Pavlik Sent: Mon 7/12/2010 9:59 AM To: cmake@cmake.org Subject: Re: [CMake] CTest examples I'm been using Boost Test, and I've written a module that lets you add the executable and the tests (where possible, individual named tests) with a single command - see my github repositories for projects that include this module. http://github.com/rpavlik What is the name of your module? Stephen BoostTestTargets.cmake - this project includes the module in the cmake dir and shows how to use it in the tests dir: http://github.com/rpavlik/physical-modeling-utilities Ryan -- Ryan Pavlik HCI Graduate Student Virtual Reality Applications Center Iowa State University rpav...@iastate.edu http://academic.cleardefinition.com Internal VRAC/HCI Site: http://tinyurl.com/rpavlik ___ 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] CMAKE_LANG_FLAGS added to link rule
On 07/12/2010 07:12 PM, Verweij, Arjen wrote: As a follow-up: redefining CMAKE_Fortran_LINK_EXECUTABLE to not include FLAGS gets rid of the CMAKE_Fortran_FLAGS.. but perhaps other (useful) stuff as well? As a sidetrack I'm starting to wonder what the purpose of CMAKE_LANG_FLAGS is. The book lists it as cmake's counterpart of the environment variable, e.g. CMAKE_CXX_FLAGS and CXXFLAGS from the shell, which means it doesn't make sense to include it when linking. Am I overlooking something here :) In GCC's documentation, one can read: -shared Produce a shared object which can then be linked with other objects to form an executable. Not all systems support this option. For predictable results, you must also specify the same set of options that were used to generate code (-fpic, -fPIC, or model suboptions) when you specify this option.[1] [1] On some systems, `gcc -shared' needs to build supplementary stub code for constructors to work. On multi-libbed systems, `gcc -shared' must select the correct support libraries to link against. Failing to supply the correct flags may lead to subtle defects. Supplying them in cases where they are not necessary is innocuous. Apparently, there may be - at least with GCC and shared libraries - a need to specify flags on the link line if they have been specified on the compile line before. Though, I don't know an example of a damaged binary due to different sets of flags for compiling and linking. Regards, Michael ___ 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] CTest examples
Hi Bo, We put together a Wiki page comparing Boost Testing and Google Test in ITK. It has examples of how to write (ITK) tests in both frameworks and CTest integration. http://www.itk.org/Wiki/Proposals:Increasing_ITK_Code_Coverage -dan On 7/9/10 6:37 AM, Bo Thorsen b...@askmonty.org wrote: Hi people, I have converted a set of applications to cmake and cpack, and now have my eyes set on ctest. I'd like to hear if someone here has some good advice, or links to good advice, on how to structure tests. I'm searching for help on how to put different tests into what executables. On how to handle multiple tests on each classes, on how to best structure the test of the static libraries (all of those are part of the source tree) that are linked in to the application. And on how to test classes from the main application itself. I have read the ctest FAQ, documentation etc. and still don't know anything that help me write the actual test code. From the looks of it, ctest only provides the framework to run a test, no help is given to write the code of the tests themselves, is this right? I have previously been using cppunit, and it looks like this will still be useful. To sum it up, I'm looking for real life advice on what you guys have done with ctest. This information seem almost completely missing on the net, where all searches on ctest leads to useless presentation on ctest features. Cheers, Bo Thorsen. Monty Program AB. -- Daniel Blezek, PhD Medical Imaging Informatics Innovation Center P 127 or (77) 8 8886 T 507 538 8886 E blezek.dan...@mayo.edu Mayo Clinic 200 First St. S.W. Harwick SL-44 Rochester, MN 55905 mayoclinic.org ___ 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
[Cmake-commits] CMake branch, next, updated. v2.8.2-225-g09db2df
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, next has been updated
via 09db2df2ad59f3e1b087f8b9a5d977496c3d60d2 (commit)
via 46df0b44ac97859ab40dd0aa03ceca297a455587 (commit)
from aa048e7d08762b24aae44df9265c3de9417b0be4 (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=09db2df2ad59f3e1b087f8b9a5d977496c3d60d2
commit 09db2df2ad59f3e1b087f8b9a5d977496c3d60d2
Merge: aa048e7 46df0b4
Author: David Cole david.c...@kitware.com
AuthorDate: Mon Jul 12 16:51:17 2010 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Mon Jul 12 16:51:17 2010 -0400
Merge branch 'ctest-file-checksum' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46df0b44ac97859ab40dd0aa03ceca297a455587
commit 46df0b44ac97859ab40dd0aa03ceca297a455587
Author: David Cole david.c...@kitware.com
AuthorDate: Mon Jul 12 16:48:38 2010 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Mon Jul 12 16:48:38 2010 -0400
Activate retry code on any curl submit failure.
Previously, we were only going into the retry block
for time out conditions. But a could not connect
response, or really any sort of curl failure, is
also a condition where we should retry the submit
if the user has requested a retry.
diff --git a/Source/CTest/cmCTestSubmitHandler.cxx
b/Source/CTest/cmCTestSubmitHandler.cxx
index bfe515d..1e18259 100644
--- a/Source/CTest/cmCTestSubmitHandler.cxx
+++ b/Source/CTest/cmCTestSubmitHandler.cxx
@@ -536,8 +536,9 @@ bool cmCTestSubmitHandler::SubmitUsingHTTP(const
cmStdString localprefix,
std::endl);
}
- // If we time out or checksum fails, wait and retry
- if(res == CURLE_OPERATION_TIMEDOUT || this-HasErrors)
+ // If curl failed for any reason, or checksum fails, wait and retry
+ //
+ if(res != CURLE_OK || this-HasErrors)
{
std::string retryDelay = this-GetOption(RetryDelay) == NULL ?
: this-GetOption(RetryDelay);
@@ -552,7 +553,7 @@ bool cmCTestSubmitHandler::SubmitUsingHTTP(const
cmStdString localprefix,
for(int i = 0; i count; i++)
{
cmCTestLog(this-CTest, HANDLER_OUTPUT,
- Connection timed out, waiting delay seconds...\n);
+ Submit failed, waiting delay seconds...\n);
double stop = cmSystemTools::GetTime() + delay;
while(cmSystemTools::GetTime() stop)
@@ -582,7 +583,7 @@ bool cmCTestSubmitHandler::SubmitUsingHTTP(const
cmStdString localprefix,
this-ParseResponse(chunk);
}
- if(res != CURLE_OPERATION_TIMEDOUT !this-HasErrors)
+ if(res == CURLE_OK !this-HasErrors)
{
break;
}
---
Summary of changes:
Source/CTest/cmCTestSubmitHandler.cxx |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.2-230-g4e7b24e
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, next has been updated
via 4e7b24ea9f5ac63d04a65e184d33e09d36596e75 (commit)
via 391acdf19915b8dd48b0bbd593af8be27178ea35 (commit)
via 942060cb19adb0b8ab3971a90cab83058f23935e (commit)
via 7dd6f1d13a047ddda0300a3a544f7c700accafc4 (commit)
via 92473b32ce183dccdb2c0932ea9f7067c1a464bb (commit)
from 09db2df2ad59f3e1b087f8b9a5d977496c3d60d2 (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=4e7b24ea9f5ac63d04a65e184d33e09d36596e75
commit 4e7b24ea9f5ac63d04a65e184d33e09d36596e75
Merge: 09db2df 391acdf
Author: David Cole david.c...@kitware.com
AuthorDate: Mon Jul 12 17:52:13 2010 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Mon Jul 12 17:52:13 2010 -0400
Merge branch 'fix-failed-submit-test' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=391acdf19915b8dd48b0bbd593af8be27178ea35
commit 391acdf19915b8dd48b0bbd593af8be27178ea35
Author: David Cole david.c...@kitware.com
AuthorDate: Mon Jul 12 17:48:33 2010 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Mon Jul 12 17:48:33 2010 -0400
Add another expected output for the failed submit tests.
The CTestTestFailedSubmit-http test was failing on the
hut11 Experimental dashboards with Empty reply from
server due to a localhost settings change.
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index e00a1cc..2980c56 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1432,6 +1432,7 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
set(regex ${regex}|Error message was: )
set(regex ${regex}([Cc]ould *n.t resolve host)
set(regex ${regex}|[Cc]ould *n.t connect to host)
+ set(regex ${regex}|Empty reply from server)
set(regex ${regex}|The requested URL returned error)
set(regex ${regex}|libcurl was built with SSL disabled. https: not
supported))
set(regex ${regex}|Submission method .xmlrpc. not compiled into CTest)
---
Summary of changes:
Source/kwsys/kwsysDateStamp.cmake |2 +-
Tests/CMakeLists.txt |1 +
2 files changed, 2 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
[Cmake-commits] CMake branch, master, updated. v2.8.2-66-g6327429
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 6327429f55949702f0d0c8e2888a9ae01910382b (commit) from 942060cb19adb0b8ab3971a90cab83058f23935e (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=6327429f55949702f0d0c8e2888a9ae01910382b commit 6327429f55949702f0d0c8e2888a9ae01910382b Author: KWSys Robot kwro...@kitware.com AuthorDate: Tue Jul 13 00:01:03 2010 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Tue Jul 13 00:10:31 2010 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index f3cd598..40308e9 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2010) SET(KWSYS_DATE_STAMP_MONTH 07) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 12) +SET(KWSYS_DATE_STAMP_DAY 13) --- Summary of changes: Source/kwsys/kwsysDateStamp.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
