Re: [cmake-developers] [CMake] CTest GIT support does not properly update recursive submodules
Hi Brad,
On Mon, Feb 7, 2011 at 7:14 PM, Brad King brad.k...@kitware.com wrote:
Hi Johan,
Let's move this over to the developers' list. I'm cc-ing the users' list
just for this transition message. Thanks.
On 02/05/2011 06:50 PM, Johan Björk wrote:
The fix is extremely simple, in cmCTestGIT.cxx:266
char const* git_submodule[] = {git, submodule, update, 0};
modify to
char const* git_submodule[] = {git, submodule, update,
--recursive, 0};
This would be a nice approach, but the --recursive option was added in
Git 1.6.5, released 2009-10-10. Versions older than that were still
in common use when the submodule update code was added on 2010-05-04:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67277bac
and may still be. We have a few options:
(1) Hard-code --recursive and add a check to error out if the Git
version is not new enough.
(2) Test the Git version and pass --recursive only if new enough.
This could lead to subtle behavior differences between Git versions,
but perhaps we could print a warning.
(3) Add an interface to specify options for the invocation of the
submodule update command.
Comments?
-Brad
(2) seems both complicated and confusing for end users. I would vote for (1)
as if someone updates to the latest CMake on their machine, they shouldn't
have any issues in upgrading the git version in use.
/Johan
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011877]: ctest runs tests in different order than previous versions of ctest
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11877 == Reported By:David Cole Assigned To:David Cole == Project:CMake Issue ID: 11877 Category: CTest Reproducibility:always Severity: major Priority: normal Status: assigned Target Version: CMake 2.8.5 == Date Submitted: 2011-02-18 11:16 EST Last Modified: 2011-02-18 11:16 EST == Summary:ctest runs tests in different order than previous versions of ctest Description: Running just ctest in the build tree produces a different run order of tests than the simple top-to-bottom ordering used by previous versions. Also, ctest and ctest -N produce different orderings. Steps to Reproduce: Run ctest -N and ctest in the build tree of a project with more than a handful of tests. (Say, CMake, with its nearly 200 tests...) Expected: - same ordering between ctest -N and ctest - same ordering as ctest 2.8.3 and earlier : simple top-to-bottom in-order of add_test calls from the CMakeLists file Actual: - ctest -N order looks correct - ctest actual run order is torqued I suspect the change for http://public.kitware.com/Bug/view.php?id=11561 introduced this regression. == Issue History Date ModifiedUsername FieldChange == 2011-02-18 11:16 David Cole New Issue 2011-02-18 11:16 David Cole Status new = assigned 2011-02-18 11:16 David Cole Assigned To = David Cole == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CTest GIT support does not properly update recursive submodules
On 02/18/2011 10:00 AM, Johan Björk wrote: On Mon, Feb 7, 2011 at 7:14 PM, Brad King wrote: (1) Hard-code --recursive and add a check to error out if the Git version is not new enough. (2) seems both complicated and confusing for end users. I would vote for (1) as if someone updates to the latest CMake on their machine, they shouldn't have any issues in upgrading the git version in use. Basically this says that CTest will support only Git 1.6.5 or higher even for projects that have no submodules at all, let alone recursive ones, and even though it would work fine were it not for this option. Perhaps instead we should detect whether any submodules are present (e.g. is the .gitmodules file present at the top) and only enforce the version number in that case. Do you mind working on a patch for this please? Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] CTest GIT support does not properly update recursive submodules
On Fri, Feb 18, 2011 at 11:18 AM, Brad King brad.k...@kitware.com wrote: On 02/18/2011 10:00 AM, Johan Björk wrote: On Mon, Feb 7, 2011 at 7:14 PM, Brad King wrote: (1) Hard-code --recursive and add a check to error out if the Git version is not new enough. (2) seems both complicated and confusing for end users. I would vote for (1) as if someone updates to the latest CMake on their machine, they shouldn't have any issues in upgrading the git version in use. Basically this says that CTest will support only Git 1.6.5 or higher even for projects that have no submodules at all, let alone recursive ones, and even though it would work fine were it not for this option. Perhaps instead we should detect whether any submodules are present (e.g. is the .gitmodules file present at the top) and only enforce the version number in that case. Do you mind working on a patch for this please? Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers For what it's worth, ExternalProject already requires git 1.6.5 or later for this very reason. ExternalProject is also easily customiz-able, though, for those who hit this and need to work around it. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011880]: For Visual Studio 2010, adding /Y- (don't use precompiled headers) to a source file's properties does not remove the /Yu flag
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11880 == Reported By:Brad Town Assigned To: == Project:CMake Issue ID: 11880 Category: CMake Reproducibility:always Severity: minor Priority: low Status: new == Date Submitted: 2011-02-18 13:22 EST Last Modified: 2011-02-18 13:22 EST == Summary:For Visual Studio 2010, adding /Y- (don't use precompiled headers) to a source file's properties does not remove the /Yu flag Description: Adding the /Y- flag (don't use precompiled headers) does not remove the /Yu flag (use precompiled headers), so when viewed in Visual Studio, such a file appears to still use precompiled headers. However, the command line shows that /Y- is added and overrides /Yu. Steps to Reproduce: Consider the following: --- cut here --- if (MSVC) set_target_properties(FooProj PROPERTIES COMPILE_FLAGS /YuFoo.h) set_source_files_properties(Foo.cpp PROPERTIES COMPILE_FLAGS /YcFoo.h) set_source_files_properties(FooNotUsingPch.cpp PROPERTIES COMPILE_FLAGS /Y-) endif () --- cut here --- Adding the /Y- flag does not remove the /Yu flag, so when viewed in Visual Studio, FooNotUsingPch.cpp appears to still use precompiled headers. However, the command line shows that /Y- is added and overrides it. Additional Information: This only appears to affect how the project appears in the IDE. /Y- is not listed in cmVS10CLFlagTable.h like /Yc and /Yu are. The option for Not Using Precompiled Headers is , which in this case may not be sufficient. == Issue History Date ModifiedUsername FieldChange == 2011-02-18 13:22 Brad Town New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] determine compilers bug?
I just noticed this in CMakeDetermineCCompiler.cmake IF(NOT CMAKE_C_COMPILER) SET(CMAKE_CXX_COMPILER_INIT NOTFOUND) (notice the CXX part above?) whereas CMakeDetermineCXXCompiler.cmake has IF(NOT CMAKE_CXX_COMPILER) SET(CMAKE_CXX_COMPILER_INIT NOTFOUND) And CMakeDetermineFortranCompiler.cmake doesn't clear CMAKE_Fortran_COMPILER_INIT but uses it. The was noticed when trying to specify preferred compilers with the *_INIT variables and the CMAKE_CXX_COMPILER_INIT didn't work and C and Fortran did. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Preferred way to use 3rd-party dependencies
Dear all, I haven't been using CMake (and hence following) for almost 3 years and I suppose it has a big progress since 2.4. Now I'm looking for most kosher way to specify external dependencies for a particular project. The most straightforward way of specifying include dirs and libraries when porting from Visual Studio - is using include_directories link_directories commands. However, I heard that link_directories is not very good idea and the preferred way is using imported targets. Some libraries are internal but built by separate teams for different compilers version. Also we don't need to find library include dir's location, we know them in advance (and it is rather fixed). So may be there are some guides, and discussions or examples about recent Find* modules behavior? Thanks in advance, Yuri ___ 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] How to set definitions
ADD_DEFINITION sets the definitions for a compiler without target
binding. This means once it is used all subsequent targets and
subdirectories have these definitions
ADD_DEFINITIONS(-DHAVE_CONFIG_H -DEXCLUDE ALL_PINGUINS)
COMPILE_DEFINITIONS is a property which is used frequently with
SET_TARGET_PROPERTIES. Here the definitions are set for the target only.
SET_TARGET_PROPERTIES(_targetname PROPERTIES
COMPILE_DEFINITIONS HAVE_CONFIG_H;EXCLUDE_ALL_PINGUINS)
No -D, parameters are separated by ;
ADD_DEFINITIONS- and SET_TARGET_PROPERTIES can be mixed, depending what
you want.
Here is an nice typical example:
SET(_definitions G_LOG_DOMAIN=\Gtk\
GTK_LIBDIR=\${DGTK_LIBDIR}\
GTK_DATADIR=\${GTK_DATADIR}\
GTK_DATA_PREFIX=\/${GTK_DATA_PREFIX}\
GTK_SYSCONFDIR=\${_sysConfDir}\
GTK_VERSION=\${PACKAGE_VERSION}\
GTK_BINARY_VERSION=\${GTK_BINARY_VERSION}\
GTK_PRINT_BACKENDS=\${GTK_PRINT_BACKENDS}\
GTK_COMPILATION
GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED
GTK_PRINT_BACKEND_ENABLE_UNSUPPORTED)
SET_TARGET_PROPERTIES(${_gtkTarget} PROPERTIES
COMPILE_DEFINITIONS ${_definitions})
CMAKE_REQUIRED_DEFINITIONS is a variable which belongs to the CheckC
command-family, which is important for CTest (Not sure!). See the
documentation there.
Greetings
Micha
Am Donnerstag, den 17.02.2011, 15:30 -0200 schrieb Felipe Ferreri
Tonello:
Hello guys,
What's the difference to use add_definitions(...), CMAKE_REQUIRED_DEFINITIONS
and COMPILE_DEFINITIONS ??
I've read the documentation but I need some examples and simple discription
how to use it.
This is a contradiction in itself.
GTK_PRINT_PREVIEW_COMMAND=
- Felipe
___
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] CTest GIT support does not properly update recursive submodules
Hi Brad,
On Mon, Feb 7, 2011 at 7:14 PM, Brad King brad.k...@kitware.com wrote:
Hi Johan,
Let's move this over to the developers' list. I'm cc-ing the users' list
just for this transition message. Thanks.
On 02/05/2011 06:50 PM, Johan Björk wrote:
The fix is extremely simple, in cmCTestGIT.cxx:266
char const* git_submodule[] = {git, submodule, update, 0};
modify to
char const* git_submodule[] = {git, submodule, update,
--recursive, 0};
This would be a nice approach, but the --recursive option was added in
Git 1.6.5, released 2009-10-10. Versions older than that were still
in common use when the submodule update code was added on 2010-05-04:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67277bac
and may still be. We have a few options:
(1) Hard-code --recursive and add a check to error out if the Git
version is not new enough.
(2) Test the Git version and pass --recursive only if new enough.
This could lead to subtle behavior differences between Git versions,
but perhaps we could print a warning.
(3) Add an interface to specify options for the invocation of the
submodule update command.
Comments?
-Brad
(2) seems both complicated and confusing for end users. I would vote for (1)
as if someone updates to the latest CMake on their machine, they shouldn't
have any issues in upgrading the git version in use.
/Johan
___
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] 2.8.4 order of tests
Yup. ctest -N and ctest without -N differ in test ordering. Congratulations! You've reported the first regression bug in CMake 2.8.4! :-) I suspect the change for this bug [ http://public.kitware.com/Bug/view.php?id=11561 ] has introduced this issue. I'll make a new issue that we can hopefully address fairly soon. Thanks, David P.S. === The same build tree with a non -N ctest run gives me this: $ ctest Test project /Users/davidcole/tmp/b6 Start 27: enum 1/52 Test #27: enum . Passed0.01 sec Start 28: set_extent 2/52 Test #28: set_extent ... Passed3.66 sec Start 29: getname 3/52 Test #29: getname .. Passed0.06 sec Start 30: vfd 4/52 Test #30: vfd .. Passed0.03 sec Start 31: ntypes 5/52 Test #31: ntypes ... Passed0.17 sec Start 32: dangle 6/52 Test #32: dangle ... Passed0.18 sec Start 33: dtransform 7/52 Test #33: dtransform ... Passed0.02 sec Start 34: reserved 8/52 Test #34: reserved . Passed0.00 sec Start 35: cross_read 9/52 Test #35: cross_read ... Passed0.02 sec Start 36: freespace 10/52 Test #36: freespace Passed0.03 sec Start 37: mf 11/52 Test #37: mf ... Passed0.09 sec ... On Thu, Feb 17, 2011 at 10:41 PM, Allen D Byrne b...@hdfgroup.org wrote: David, I tried ctest -N it lies! Here is the beginning of the test.log showing the problem (peviously the tests were in test number order) : Start testing: Feb 17 21:13 CST -- 435/660 Testing: H5COPY-clear-ext-links 436/660 Testing: H5COPY-ext_link 437/660 Testing: H5COPY-ext_link_f 438/660 Testing: H5COPY-ext_dangle_noobj 439/660 Testing: H5COPY-DIFF_ext_dangle_noobj 440/660 Testing: H5COPY-ext_dangle_noobj_f 441/660 Testing: H5COPY-ext_dangle_nofile 442/660 Testing: H5COPY-DIFF_ext_dangle_nofile 443/660 Testing: H5COPY-ext_dangle_nofile_f 444/660 Testing: H5COPY-ext_link_group 445/660 Testing: H5COPY-ext_link_group_f 446/660 Testing: H5COPY-H5LS_h5copy_extlinks_src 447/660 Testing: H5STAT-h5stat_help1 448/660 Testing: H5STAT-h5stat_help2 449/660 Testing: H5STAT-h5stat_filters 450/660 Testing: H5STAT-h5stat_filters-file 451/660 Testing: H5STAT-h5stat_filters-F 452/660 Testing: H5STAT-h5stat_filters-d 453/660 Testing: H5STAT-h5stat_filters-g 454/660 Testing: H5STAT-h5stat_filters-dT 414/660 Testing: H5COPY-DIFF_grp_nested 415/660 Testing: H5COPY-simple_group 416/660 Testing: H5COPY-DIFF_simple_group 417/660 Testing: H5COPY-grp_rename 418/660 Testing: H5COPY-DIFF_grp_rename 419/660 Testing: H5COPY-grp_dsets_rename 420/660 Testing: H5COPY-DIFF_grp_dsets_rename 421/660 Testing: H5COPY-A_B1_simple 422/660 Testing: H5COPY-DIFF_A_B1_simple 423/660 Testing: H5COPY-A_B2_simple2 424/660 Testing: H5COPY-DIFF_A_B2_simple2 425/660 Testing: H5COPY-C_D_simple 426/660 Testing: H5COPY-DIFF_C_D_simple 427/660 Testing: H5COPY-E_F_grp_dsets 428/660 Testing: H5COPY-DIFF_E_F_grp_dsets 429/660 Testing: H5COPY-G_H_grp_nested 430/660 Testing: H5COPY-DIFF_G_H_grp_nested 431/660 Testing: H5COPY-H5LS_h5copytst 432/660 Testing: H5COPY-clear-refs 433/660 Testing: H5COPY-region_ref 434/660 Testing: H5COPY-H5LS_h5copy_ref 476/660 Testing: H5DUMP-thlink-4 477/660 Testing: H5DUMP-thlink-5 478/660 Testing: H5DUMP-tcomp-1 479/660 Testing: H5DUMP-tcomp-2 480/660 Testing: H5DUMP-tcomp-4 481/660 Testing: H5DUMP-tnestcomp-1 482/660 Testing: H5DUMP-tall-1 483/660 Testing: H5DUMP-tall-2 484/660 Testing: H5DUMP-tall-3 485/660 Testing: H5DUMP-tloop-1 486/660 Testing: H5DUMP-tstr-1 487/660 Testing: H5DUMP-tstr-2 488/660 Testing: H5DUMP-tsaf 489/660 Testing: H5DUMP-tvldtypes1 490/660 Testing: H5DUMP-tvldtypes2 491/660 Testing: H5DUMP-tvldtypes3 492/660 Testing: H5DUMP-tvldtypes4 493/660 Testing: H5DUMP-tvldtypes5 494/660 Testing: H5DUMP-tvlstr 495/660 Testing: H5DUMP-tarray1 455/660 Testing: H5STAT-h5stat_filters-UD 456/660 Testing: H5STAT-h5stat_filters-UT 457/660 Testing: H5STAT-h5stat_tsohm 458/660 Testing: H5STAT-h5stat_newgrat 459/660 Testing: H5STAT-h5stat_newgrat-UG 460/660 Testing: H5STAT-h5stat_newgrat-UA 461/660 Testing: H5DUMP-tgroup-1 462/660 Testing: H5DUMP-tgroup-2 463/660 Testing: H5DUMP-tdset-1 464/660 Testing: H5DUMP-tdset-2 465/660 Testing: H5DUMP-tattr-1 466/660 Testing: H5DUMP-tattr-2 467/660 Testing: H5DUMP-tattr-3 468/660 Testing: H5DUMP-tnamed_dtype_attr 469/660 Testing: H5DUMP-tslink-1 470/660 Testing: H5DUMP-tudlink-1 471/660 Testing: H5DUMP-tslink-2 472/660 Testing: H5DUMP-tudlink-2 473/660 Testing: H5DUMP-thlink-1 474/660 Testing:
[CMake] CTest in a cross-compiling environment
Hi, Are there any CMake solutions for running tests in a cross-compiling environment? Right now I have a lovely test suite that runs over sixty different executables using the standard CMake and CTest setup. It works exactly as I want under Linux, but now I need to run it on a cross-compiling platform (in fact, two cross-compiling platforms: BG/P and Cray XT5). I don't have cmake compiled for the target platform, so I can't just run ctest. Surely there must be other people with this problem, but this mornings Google searches aren't turning up anything for me. Thanks for any help, Jim Amundson P.S. The tests themselves are either Boost Test executables or python scripts to be run with nose. Running the tests themselves shouldn't present any problem. ___ 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] Gyp VS CMake
Hello, There is nothing wrong with another build system. Not all build systems fit everyone needs, much like subversion and git being suitable for different development styles. When I have the time, I will start developing my own build system. It will have the following proposed features. 1. Dependency generation by the compiler, so that the include generator understands the c-preprocessor. 2. Tcl (or other) scripting language, which has clearly defined variable scoping rules and well understood semantics. 3. Ability to generate object files and use the same ones in multiple contexts. 4. Ninja generator or built in backend instead of per platform native backends. I've gotten the impression from the Cmake mailing list the first 3 are not being planned for CMake. Juan ___ 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 in a cross-compiling environment
On 02/18/2011 04:36 PM, James Amundson wrote:
Hi,
Are there any CMake solutions for running tests in a cross-compiling
environment? Right now I have a lovely test suite that runs over sixty
different executables using the standard CMake and CTest setup. It works
exactly as I want under Linux, but now I need to run it on a
cross-compiling platform (in fact, two cross-compiling platforms: BG/P
and Cray XT5). I don't have cmake compiled for the target platform, so I
can't just run ctest. Surely there must be other people with this
problem, but this mornings Google searches aren't turning up anything
for me.
Thanks for any help,
Jim Amundson
P.S. The tests themselves are either Boost Test executables or python
scripts to be run with nose. Running the tests themselves shouldn't
present any problem.
Mhhm, that's a problem I've also been thinking about just recently.
Probably you'll have to invoke the tests through a wrapper script which
invokes aprun appropriately on the XT5 and whatever is required on the
BG/P. Something like this:
add_test(NAME test1
COMMAND ${TEST_LAUNCHER} -N 6 -n 12 -d 2 $TARGET_FILE:test1)
Where TEST_LAUNCHER points to said script which parses the options (e.g.
-N number of ranks per node, -n total number of ranks, -d number of
threads), sets required environment variables (e.g. OMP_NUM_THREADS=2)
and calls the appropriate launcher for the platform it's running on.
Like this, CTest only runs on the login node and runs the tests on the
compute nodes.
Probably it would be best to run this from an interactive session (with
SLURM use salloc, other queuing systems will have similar possibilities).
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] Cross-compiling: Cmake compiler and ABI check don´t work
On Friday 18 February 2011, Schmid Alexander wrote:
Hi,
of course, I´d like to have you think further about it, so here you go...
;-)
This is the toolchain file I use.
The specialty about is that I want to use the ARMCC as compiler and an
SDK-provided linker tool for linking.
# this one is important
SET( CMAKE_SYSTEM_NAME Generic )
# this one not so much
SET( CMAKE_SYSTEM_VERSION 1 )
#
---
-- # setup local variables used
#
---
--
SET( SDK1_ROOT $ENV{PROJ_ROOT}\\tools\\Sdk1 )
message( STATUS The SDK1 can be found at ${SDK1_ROOT} )
SET( SDK1_INCLUDE ${SDK1_ROOT}/include )
STRING( REPLACE \\ / SDK1_INCLUDE ${SDK1_INCLUDE} )
SET( SDK1_LIB ${SDK1_ROOT}/lib )
STRING( REPLACE \\ / SDK1_LIB ${SDK1_LIB} )
SET( SDK2_ROOT $ENV{PROJ_ROOT}\\tools\\Sdk2 )
message( STATUS The SDK2 can be found at ${SDK2_ROOT} )
SET( SDK2_INCLUDE ${SDK2_ROOT}/include )
STRING( REPLACE \\ / SDK2_INCLUDE ${SDK2_INCLUDE} )
SET( SDK2_LIB ${SDK2_ROOT}/lib )
STRING( REPLACE \\ / SDK2_LIB ${SDK2_LIB} )
SET( RVCT40_BIN $ENV{RVCT40BIN} )
message( STATUS The ARM Tools can be found at ${RVCT40_BIN} )
Does it work if you replace the all the $ENV{}s with hardcoded paths ?
Please try that and let me know if it works then, so we can figure out a
solution.
Alex
___
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] Gyp VS CMake
On 02/18/2011 04:48 PM, j s wrote: Hello, There is nothing wrong with another build system. Not all build systems fit everyone needs, much like subversion and git being suitable for different development styles. When I have the time, I will start developing my own build system. It will have the following proposed features. Just my thoughts below, giving some reasons I think CMake is the way it is. 1. Dependency generation by the compiler, so that the include generator understands the c-preprocessor. Well, cl.exe for one doesn't do this trick. This means, you'll have to put it in your build system, and once you've done that, why should you use the compiler then? Especially, since you'll want to be consistent across platforms. 2. Tcl (or other) scripting language, which has clearly defined variable scoping rules and well understood semantics. There are many pros for this idea, but a very important con: People will use it as a general purpose programming language (see what often happens to SCons projects). Even CMake has this problem to a lesser extent (IMHO mainly because it's a PITA to program ;-)). But I think some people at Kitware are/were experimenting with Python bindings... 3. Ability to generate object files and use the same ones in multiple contexts. It's very easy to shoot yourself in the foot with that. Different uses might require different compiler flags on different platforms. 4. Ninja generator or built in backend instead of per platform native backends. I also was wishing for some native generator for CMake recently... I've gotten the impression from the Cmake mailing list the first 3 are not being planned for CMake. Juan 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] 2.8.4 order of tests
Bug reported: http://public.kitware.com/Bug/view.php?id=11877 On Fri, Feb 18, 2011 at 10:30 AM, David Cole david.c...@kitware.com wrote: Yup. ctest -N and ctest without -N differ in test ordering. Congratulations! You've reported the first regression bug in CMake 2.8.4! :-) I suspect the change for this bug [ http://public.kitware.com/Bug/view.php?id=11561 ] has introduced this issue. I'll make a new issue that we can hopefully address fairly soon. Thanks, David P.S. === The same build tree with a non -N ctest run gives me this: $ ctest Test project /Users/davidcole/tmp/b6 Start 27: enum 1/52 Test #27: enum . Passed 0.01 sec Start 28: set_extent 2/52 Test #28: set_extent ... Passed 3.66 sec Start 29: getname 3/52 Test #29: getname .. Passed 0.06 sec Start 30: vfd 4/52 Test #30: vfd .. Passed 0.03 sec Start 31: ntypes 5/52 Test #31: ntypes ... Passed 0.17 sec Start 32: dangle 6/52 Test #32: dangle ... Passed 0.18 sec Start 33: dtransform 7/52 Test #33: dtransform ... Passed 0.02 sec Start 34: reserved 8/52 Test #34: reserved . Passed 0.00 sec Start 35: cross_read 9/52 Test #35: cross_read ... Passed 0.02 sec Start 36: freespace 10/52 Test #36: freespace Passed 0.03 sec Start 37: mf 11/52 Test #37: mf ... Passed 0.09 sec ... On Thu, Feb 17, 2011 at 10:41 PM, Allen D Byrne b...@hdfgroup.org wrote: David, I tried ctest -N it lies! Here is the beginning of the test.log showing the problem (peviously the tests were in test number order) : Start testing: Feb 17 21:13 CST -- 435/660 Testing: H5COPY-clear-ext-links 436/660 Testing: H5COPY-ext_link 437/660 Testing: H5COPY-ext_link_f 438/660 Testing: H5COPY-ext_dangle_noobj 439/660 Testing: H5COPY-DIFF_ext_dangle_noobj 440/660 Testing: H5COPY-ext_dangle_noobj_f 441/660 Testing: H5COPY-ext_dangle_nofile 442/660 Testing: H5COPY-DIFF_ext_dangle_nofile 443/660 Testing: H5COPY-ext_dangle_nofile_f 444/660 Testing: H5COPY-ext_link_group 445/660 Testing: H5COPY-ext_link_group_f 446/660 Testing: H5COPY-H5LS_h5copy_extlinks_src 447/660 Testing: H5STAT-h5stat_help1 448/660 Testing: H5STAT-h5stat_help2 449/660 Testing: H5STAT-h5stat_filters 450/660 Testing: H5STAT-h5stat_filters-file 451/660 Testing: H5STAT-h5stat_filters-F 452/660 Testing: H5STAT-h5stat_filters-d 453/660 Testing: H5STAT-h5stat_filters-g 454/660 Testing: H5STAT-h5stat_filters-dT 414/660 Testing: H5COPY-DIFF_grp_nested 415/660 Testing: H5COPY-simple_group 416/660 Testing: H5COPY-DIFF_simple_group 417/660 Testing: H5COPY-grp_rename 418/660 Testing: H5COPY-DIFF_grp_rename 419/660 Testing: H5COPY-grp_dsets_rename 420/660 Testing: H5COPY-DIFF_grp_dsets_rename 421/660 Testing: H5COPY-A_B1_simple 422/660 Testing: H5COPY-DIFF_A_B1_simple 423/660 Testing: H5COPY-A_B2_simple2 424/660 Testing: H5COPY-DIFF_A_B2_simple2 425/660 Testing: H5COPY-C_D_simple 426/660 Testing: H5COPY-DIFF_C_D_simple 427/660 Testing: H5COPY-E_F_grp_dsets 428/660 Testing: H5COPY-DIFF_E_F_grp_dsets 429/660 Testing: H5COPY-G_H_grp_nested 430/660 Testing: H5COPY-DIFF_G_H_grp_nested 431/660 Testing: H5COPY-H5LS_h5copytst 432/660 Testing: H5COPY-clear-refs 433/660 Testing: H5COPY-region_ref 434/660 Testing: H5COPY-H5LS_h5copy_ref 476/660 Testing: H5DUMP-thlink-4 477/660 Testing: H5DUMP-thlink-5 478/660 Testing: H5DUMP-tcomp-1 479/660 Testing: H5DUMP-tcomp-2 480/660 Testing: H5DUMP-tcomp-4 481/660 Testing: H5DUMP-tnestcomp-1 482/660 Testing: H5DUMP-tall-1 483/660 Testing: H5DUMP-tall-2 484/660 Testing: H5DUMP-tall-3 485/660 Testing: H5DUMP-tloop-1 486/660 Testing: H5DUMP-tstr-1 487/660 Testing: H5DUMP-tstr-2 488/660 Testing: H5DUMP-tsaf 489/660 Testing: H5DUMP-tvldtypes1 490/660 Testing: H5DUMP-tvldtypes2 491/660 Testing: H5DUMP-tvldtypes3 492/660 Testing: H5DUMP-tvldtypes4 493/660 Testing: H5DUMP-tvldtypes5 494/660 Testing: H5DUMP-tvlstr 495/660 Testing: H5DUMP-tarray1 455/660 Testing: H5STAT-h5stat_filters-UD 456/660 Testing: H5STAT-h5stat_filters-UT 457/660 Testing: H5STAT-h5stat_tsohm 458/660 Testing: H5STAT-h5stat_newgrat 459/660 Testing: H5STAT-h5stat_newgrat-UG 460/660 Testing: H5STAT-h5stat_newgrat-UA 461/660 Testing: H5DUMP-tgroup-1 462/660 Testing: H5DUMP-tgroup-2 463/660 Testing: H5DUMP-tdset-1 464/660 Testing: H5DUMP-tdset-2 465/660 Testing: H5DUMP-tattr-1 466/660 Testing: H5DUMP-tattr-2 467/660 Testing: H5DUMP-tattr-3 468/660 Testing: H5DUMP-tnamed_dtype_attr 469/660 Testing: H5DUMP-tslink-1
Re: [CMake] CTest in a cross-compiling environment
On Friday 18 February 2011, James Amundson wrote: Hi, Are there any CMake solutions for running tests in a cross-compiling environment? Right now I have a lovely test suite that runs over sixty different executables using the standard CMake and CTest setup. It works exactly as I want under Linux, but now I need to run it on a cross-compiling platform (in fact, two cross-compiling platforms: BG/P and Cray XT5). I don't have cmake compiled for the target platform, so I can't just run ctest. Surely there must be other people with this problem, but this mornings Google searches aren't turning up anything for me. When cmake is crosscompiling, it assumes that the executables it has built cannot be run on the build host. CMake does not provide any special mechanisms to run the executables remote or in a VM or something. Alex ___ 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] Gyp VS CMake
Hello, Responses inline to 1 and 2 below: Thanks, Juan On Fri, Feb 18, 2011 at 10:16 AM, Michael Wild them...@gmail.com wrote: On 02/18/2011 04:48 PM, j s wrote: Hello, There is nothing wrong with another build system. Not all build systems fit everyone needs, much like subversion and git being suitable for different development styles. When I have the time, I will start developing my own build system. It will have the following proposed features. Just my thoughts below, giving some reasons I think CMake is the way it is. 1. Dependency generation by the compiler, so that the include generator understands the c-preprocessor. Well, cl.exe for one doesn't do this trick. This means, you'll have to put it in your build system, and once you've done that, why should you use the compiler then? Especially, since you'll want to be consistent across platforms. cl.exe does this trick cl.exe /showincludes http://www.conifersystems.com/2008/10/09/dependencies-from-showincludes/ 2. Tcl (or other) scripting language, which has clearly defined variable scoping rules and well understood semantics. There are many pros for this idea, but a very important con: People will use it as a general purpose programming language (see what often happens to SCons projects). Even CMake has this problem to a lesser extent (IMHO mainly because it's a PITA to program ;-)). But I think some people at Kitware are/were experimenting with Python bindings... This brings up a new requirement: 5. Clear delineation when things are done at configuration time, and things are done at build time. 3. Ability to generate object files and use the same ones in multiple contexts. It's very easy to shoot yourself in the foot with that. Different uses might require different compiler flags on different platforms. 4. Ninja generator or built in backend instead of per platform native backends. I also was wishing for some native generator for CMake recently... I've gotten the impression from the Cmake mailing list the first 3 are not being planned for CMake. Juan 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 ___ 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] Gyp VS CMake
On Fri, Feb 18, 2011 at 8:16 AM, Michael Wild them...@gmail.com wrote: 2. Tcl (or other) scripting language, which has clearly defined variable scoping rules and well understood semantics. There are many pros for this idea, but a very important con: People will use it as a general purpose programming language (see what often happens to SCons projects). Even CMake has this problem to a lesser extent (IMHO mainly because it's a PITA to program ;-)). But I think some people at Kitware are/were experimenting with Python bindings... Really?!? I'm actually *generating* CMakeLists.txt files with python in an effort to work around the entire cmake language and integrate better with things that need to know about the build, but aren't the build system proper. ___ 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] Gyp VS CMake
On Fri, Feb 18, 2011 at 2:42 PM, Troy Straszheim straszh...@willowgarage.com wrote: On Fri, Feb 18, 2011 at 8:16 AM, Michael Wild them...@gmail.com wrote: 2. Tcl (or other) scripting language, which has clearly defined variable scoping rules and well understood semantics. There are many pros for this idea, but a very important con: People will use it as a general purpose programming language (see what often happens to SCons projects). Even CMake has this problem to a lesser extent (IMHO mainly because it's a PITA to program ;-)). But I think some people at Kitware are/were experimenting with Python bindings... Really?!? I'm actually *generating* CMakeLists.txt files with python in an effort to work around the entire cmake language and integrate better with things that need to know about the build, but aren't the build system proper. No, not really. (At least not to the best of my knowledge...) There was an experiment a few years ago using Lua, but it was shelved and has not been revisited. Nothing in python that I know of. Cheers, David ___ 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] Gyp VS CMake
On 18.02.2011 20:48, David Cole wrote: There are many pros for this idea, but a very important con: People will use it as a general purpose programming language (see what often happens to SCons projects). Even CMake has this problem to a lesser extent (IMHO mainly because it's a PITA to program ;-)). But I think some people at Kitware are/were experimenting with Python bindings... Really?!? I'm actually *generating* CMakeLists.txt files with python in an effort to work around the entire cmake language and integrate better with things that need to know about the build, but aren't the build system proper. No, not really. (At least not to the best of my knowledge...) There was an experiment a few years ago using Lua, but it was shelved and has not been revisited. Experiment with Lua is here: http://www.assembla.com/wiki/show/CMakeLua and an experiment with Qt's JavaScript with the advantage of having a debugger with a GUI: http://sourceforge.net/projects/cmakescript/ Peter ___ 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] New warnings in CMake 2.8.4-rc2
-- Forwarded message -- From: Emmanuel Blot eblot...@gmail.com Date: Fri, Feb 18, 2011 at 11:48 PM Subject: Re: [CMake] New warnings in CMake 2.8.4-rc2 To: David Cole david.c...@kitware.com If a variable is not used, then simply do not define it on the cmake command line. Thanks, but I simply can't. If I could, I would have done it since 2.8.4-RC1 ;-) Basically, we call several CMake projects from the same shell scripts, and each CMake invokation receive the same set of global parameters. The same way you can invoke a compiler with several -D options and safely ignore the definitions you do not care about. Or the same way you can place as many variables as you want in the environment and let a program decides whether it wants to use it or not. I'm looking for the same feature for CMake. I used to do it with -D option switch, it seems I can't do it anymore. The other option is simply to ignore all of our was not used output. They are only warnings. They do not actually affect the generated build tree. But we just don't want warnings. False warnings simply distract the developer that have no choice but start ignoring them - and fail to detect real and useful ones. I guess I don't understand your big picture here. It seems to me that it should be easy to resolve this one way or another, even if it's not pretty and elegant. Sure. I'm just looking to invoke CMake with a set of variables, some of which being useful for a given CMake script, some others being safely ignored - as they used to be, BTW. How to do this? make accepts a random list of definitions: make key1=value1 key2=value2 ... gcc accepts a random list of definitions: gcc -DKEY1=value1 -DKEY2=value2 What is the equivalent way of passing such arguments to a CMake script ? Thanks Emmanuel. ___ 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] Gyp VS CMake
On Thu, Feb 17, 2011 at 4:23 PM, Bill Hoffman bill.hoff...@kitware.com wrote: I think one of their main points was to generate standalone projects that do not require CMake to build. Yes. As mentioned in point 5. This will never happen with CMake. CMake will always be required to be on the machine doing the build. There is just no other way to do system introspection. Also, if you don't have something like CMake around it is hard to write cross platform build files that are complex in anyway (i.e. needs to copy files at build time). Actually, it could happen, or at least the requirement could be softened. I developed a bootstrapper for Wt ( http://webtoolkit.eu ) which requires nothing more than a C++ compiler and a command prompt (Windows) or bash (Unix) to build. It's essentially a couple of scripts which download CMake and some basic dependencies, then ExternalProject_Add all other dependencies, making the project buildable in a self-contained directory, including all the dependencies. Maybe some option could be added to CMake to generate such scripts and make it easier to bootstrap? (Details on what I did here: Bootstrap your CMake project - http://www.elpauer.org/?p=614 ) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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] Gyp VS CMake
This will never happen with CMake. CMake will always be required to be on the machine doing the build. There is just no other way to do system introspection. Also, if you don't have something like CMake around it is hard to write cross platform build files that are complex in anyway (i.e. needs to copy files at build time). Actually, it could happen, or at least the requirement could be softened. I developed a bootstrapper for Wt ( http://webtoolkit.eu ) which requires nothing more than a C++ compiler and a command prompt (Windows) or bash (Unix) to build. It's essentially a couple of scripts which download CMake and some basic dependencies, then ExternalProject_Add all other dependencies, making the project buildable in a self-contained directory, including all the dependencies. Maybe some option could be added to CMake to generate such scripts and make it easier to bootstrap? (Details on what I did here: Bootstrap your CMake project - http://www.elpauer.org/?p=614 ) Sure, bootstrapping CMake is possible, and consistent with the design goals, and the reason CMake does not use python or any other language. CMake was designed to have one dependency, a C++ compiler. The thought was that if you were going to build a C++ program, you would have to have a C++ compiler. However, for the CMake can not be installed crowd, bootstrapping somehow is not an option... Nice blog by the way, thanks for the CMake compliments! -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
[Cmake-commits] CMake branch, next, updated. v2.8.4-927-g7cc232e
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 7cc232e7d010e242a7703c4d48f7096ea5c6072e (commit) via 16b99e6caec41aaa4366b5f49e2d3b2de1225001 (commit) from fad063ccb575466a2fe6050a352aa6cbc5df2494 (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=7cc232e7d010e242a7703c4d48f7096ea5c6072e commit 7cc232e7d010e242a7703c4d48f7096ea5c6072e Merge: fad063c 16b99e6 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Feb 18 08:53:28 2011 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Feb 18 08:53:28 2011 -0500 Merge branch 'master' into next --- 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
[Cmake-commits] CMake branch, next, updated. v2.8.4-929-g633f628
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 633f6285702d4c044735f119f1b7ef645f808eb6 (commit)
via 42fe75460ab34786a48431e804e31f2d91104104 (commit)
from 7cc232e7d010e242a7703c4d48f7096ea5c6072e (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=633f6285702d4c044735f119f1b7ef645f808eb6
commit 633f6285702d4c044735f119f1b7ef645f808eb6
Merge: 7cc232e 42fe754
Author: Zach Mullen zach.mul...@kitware.com
AuthorDate: Fri Feb 18 12:17:47 2011 -0500
Commit: Zach Mullen zach.mul...@kitware.com
CommitDate: Fri Feb 18 12:17:47 2011 -0500
Merge branch 'upload-built-files' into next
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=42fe75460ab34786a48431e804e31f2d91104104
commit 42fe75460ab34786a48431e804e31f2d91104104
Author: Zach Mullen zach.mul...@kitware.com
AuthorDate: Fri Feb 18 12:11:51 2011 -0500
Commit: Zach Mullen zach.mul...@kitware.com
CommitDate: Fri Feb 18 12:11:51 2011 -0500
Implement ctest_upload command
diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index 7722c19..e284967 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -343,7 +343,7 @@ TARGET_LINK_LIBRARIES(CMakeLib cmsys
${CMAKE_TAR_LIBRARIES} ${CMAKE_COMPRESS_LIBRARIES}
${CMAKE_CURL_LIBRARIES} )
-# On Apple we need Carbon
+# On Apple we need CoreFoundation
IF(APPLE)
TARGET_LINK_LIBRARIES(CMakeLib -framework CoreFoundation)
ENDIF(APPLE)
@@ -394,6 +394,8 @@ SET(CTEST_SRCS cmCTest.cxx
CTest/cmCTestTestHandler.cxx
CTest/cmCTestUpdateCommand.cxx
CTest/cmCTestUpdateHandler.cxx
+ CTest/cmCTestUploadCommand.cxx
+ CTest/cmCTestUploadHandler.cxx
CTest/cmCTestVC.cxx
CTest/cmCTestVC.h
@@ -465,7 +467,7 @@ IF(APPLE)
ADD_EXECUTABLE(OSXScriptLauncher
CPack/OSXScriptLauncher.cxx)
TARGET_LINK_LIBRARIES(OSXScriptLauncher cmsys)
- TARGET_LINK_LIBRARIES(OSXScriptLauncher -framework Carbon)
+ TARGET_LINK_LIBRARIES(OSXScriptLauncher -framework CoreFoundation)
ENDIF(APPLE)
# Build CMake executable
diff --git a/Source/CTest/cmCTestScriptHandler.cxx
b/Source/CTest/cmCTestScriptHandler.cxx
index fdf17e0..5841b8d 100644
--- a/Source/CTest/cmCTestScriptHandler.cxx
+++ b/Source/CTest/cmCTestScriptHandler.cxx
@@ -50,6 +50,7 @@
#include cmCTestSubmitCommand.h
#include cmCTestTestCommand.h
#include cmCTestUpdateCommand.h
+#include cmCTestUploadCommand.h
#define CTEST_INITIAL_CMAKE_OUTPUT_FILE_NAME CTestInitialCMakeOutput.log
@@ -164,7 +165,7 @@ cmCTestScriptHandler::~cmCTestScriptHandler()
//--
// just adds an argument to the vector
-void cmCTestScriptHandler::AddConfigurationScript(const char *script,
+void cmCTestScriptHandler::AddConfigurationScript(const char *script,
bool pscope)
{
this-ConfigurationScripts.push_back(script);
@@ -224,12 +225,12 @@ int cmCTestScriptHandler::ExecuteScript(const
std::string total_script_arg)
argv.push_back(-SR);
argv.push_back(total_script_arg.c_str());
- cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT,
- Executable for CTest is:
+ cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT,
+ Executable for CTest is:
this-CTest-GetCTestExecutable() \n);
// now pass through all the other arguments
- std::vectorcmStdString initArgs =
+ std::vectorcmStdString initArgs =
this-CTest-GetInitialCommandLineArguments();
//*** need to make sure this does not have the current script ***
for(size_t i=1; i initArgs.size(); ++i)
@@ -252,7 +253,7 @@ int cmCTestScriptHandler::ExecuteScript(const std::string
total_script_arg)
int pipe = cmSystemTools::WaitForLine(cp, line, 100.0, out, err);
while(pipe != cmsysProcess_Pipe_None)
{
-cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT, Output:
+cmCTestLog(this-CTest, HANDLER_VERBOSE_OUTPUT, Output:
line \n);
if(pipe == cmsysProcess_Pipe_STDERR)
{
@@ -264,7 +265,7 @@ int cmCTestScriptHandler::ExecuteScript(const std::string
total_script_arg)
}
pipe = cmSystemTools::WaitForLine(cp, line, 100, out, err);
}
-
+
// Properly handle output of the build command
cmsysProcess_WaitForExit(cp, 0);
int result = cmsysProcess_GetState(cp);
@@ -278,7 +279,7 @@ int cmCTestScriptHandler::ExecuteScript(const std::string
total_script_arg)
{
retVal = cmsysProcess_GetExitException(cp);
cmCTestLog(this-CTest, ERROR_MESSAGE, \tThere was an exception:
-cmsysProcess_GetExceptionString(cp)
+
[Cmake-commits] CMake branch, next, updated. v2.8.4-931-g268b337
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 268b33797d27b0255587d972d5bebef048c167b7 (commit) via 8af8eab7a43aa80ba89d082e23928e19265be885 (commit) from 633f6285702d4c044735f119f1b7ef645f808eb6 (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=268b33797d27b0255587d972d5bebef048c167b7 commit 268b33797d27b0255587d972d5bebef048c167b7 Merge: 633f628 8af8eab Author: David Cole david.c...@kitware.com AuthorDate: Fri Feb 18 13:30:02 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Feb 18 13:30:02 2011 -0500 Merge topic 'fix-11877-sort-tests-correctly' into next 8af8eab Use stable_sort to preserve test order (#11877) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8af8eab7a43aa80ba89d082e23928e19265be885 commit 8af8eab7a43aa80ba89d082e23928e19265be885 Author: David Cole david.c...@kitware.com AuthorDate: Fri Feb 18 13:10:26 2011 -0500 Commit: David Cole david.c...@kitware.com CommitDate: Fri Feb 18 13:10:26 2011 -0500 Use stable_sort to preserve test order (#11877) Using sort results in a possibly-modified sorting when all elements are tied - use stable_sort instead to preserve the original ordering of tied elements. diff --git a/Source/CTest/cmCTestMultiProcessHandler.cxx b/Source/CTest/cmCTestMultiProcessHandler.cxx index f3a4457..2cae802 100644 --- a/Source/CTest/cmCTestMultiProcessHandler.cxx +++ b/Source/CTest/cmCTestMultiProcessHandler.cxx @@ -484,7 +484,7 @@ void cmCTestMultiProcessHandler::CreateTestCostList() } TestComparator comp(this); - std::sort(SortedTests.begin(), SortedTests.end(), comp); + std::stable_sort(SortedTests.begin(), SortedTests.end(), comp); } //- --- Summary of changes: Source/CTest/cmCTestMultiProcessHandler.cxx |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
[Cmake-commits] CMake branch, master, updated. v2.8.4-5-g9e81ddd
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 9e81dddc4f1a85345fac95d30edc07d954166123 (commit) from 16b99e6caec41aaa4366b5f49e2d3b2de1225001 (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=9e81dddc4f1a85345fac95d30edc07d954166123 commit 9e81dddc4f1a85345fac95d30edc07d954166123 Author: KWSys Robot kwro...@kitware.com AuthorDate: Sat Feb 19 00:01:08 2011 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sat Feb 19 00:10:09 2011 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index a4b408a..c596da2 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 02) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 18) +SET(KWSYS_DATE_STAMP_DAY 19) --- 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
