Re: [cmake-developers] Perforce Patch for CTest
On 10/24/2013 03:11 AM, Rolf Eike Beer wrote:
CMake/Source/CTest/cmCTestP4.cxx: In member function ‘virtual void
cmCTestP4::LoadRevisions()’:
CMake/Source/CTest/cmCTestP4.cxx:469:32: warning: conversion to ‘int’
from ‘std::vectorstd::basic_stringchar ::size_type {aka long
unsigned int}’ may alter its value [-Wconversion]
Also std::size_t does not work on VS 6. Both fixed:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b6fbd681
-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] ExternalProject update target dependencies
Hello all, I have another issue with ExternalProject. If I add 2 external projects (A and B), with B DEPENDS=A, and STEP_TARGETS=update, I expect to be able to update B without updating, building and installing A, since just updating the code is obviously not dependent. I tried to look at ExternalProject.cmake, and the code seems to handle this exactly as I expect, setting the dependency only for the configure command. * update depends on download * download depends on gitinfo.txt and mkdir * mkdir depends on nothing * gitinfo.txt is generated by configure_file Unfortunately, for some reason that I cannot understand, it does not work as expected, and if I run make B-update, A is built before B update. You can reproduce this issue with this small test: https://github.com/drdanz/ep_test Any idea about the reason why this happens and how to fix this? Cheers, Daniele -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Perforce Patch for CTest
On 10/24/2013 08:17 AM, Brad King wrote: Also std::size_t does not work on VS 6. Both fixed: Also a couple fixes to the test: CTest.UpdateP4: Fix test when p4 client is not in PATH http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ee51ec64eb CTest.UpdateP4: Run test in directory with space in its name http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a752135 -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Testing CMake
Hello, I've been wondering about the test setup in Tests/CMakeLists.txt. Is CMAKE_CTEST_COMMAND in that context the newly build ctest or the old one that performed the build? Does CMAKE_CTEST_COMMAND when invoked with --build-and-test perhaps run that build and test with the new binaries? I'm basically trying to figure out which version of cmake I can expect for which cmake/ctest scripts and whether I am correctly testing newly implemented behavior or incorrectly testing the outdated behavior from an previous build. Some of the scripts reference ancient versions of cmake and I am scared of breaking them by introducing features that are not available in them. Are there additional reasons why newer features should be kept out of certain scripts? Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CTest: Request review of topic ctest-fix-run-serial
Thanks Bill, I think I can probably fix that by replacing the insert with a manual loop. SSH access is being blocked here so I probably wont get to fix it before I get home but looks like the client only builds nightly anyway :) Nils On 10/24/2013 03:40 PM, Bill Hoffman wrote: On 10/24/2013 8:58 AM, Nils Gladitz wrote: Had some trouble with my new test and multi configuration generators at first but the incomming dashboard results look like I got that fixed now :) Thanks again! Looks like there was a build failure here: http://open.cdash.org/viewBuildError.php?buildid=3071938 -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] C++11 and target_compiler_feature proposal
Brad King wrote: On 10/23/2013 05:59 PM, Stephen Kelly wrote: CMAKE_CXX_COMPILER is always set to the proper full path these days, even in the IDE generators, so I wonder if we could actually run it against the header file to detect the features available for the current compiler instead of hard-coding a table in the platform information files. Then the checks would all be done in one place via the preprocessor and __has_feature if available. I've implemented this and merged it to next for dashboard testing. Please see the hythloth.kitware Linux64-gnu build entry on the dashboard for some documentation errors reported by sphinx-build. Also when you run the compiler you need to capture all stdout/stderr so that it never leaks through to the user-visible cmake configuration output. The RunCMake.* tests that failed last night were mostly due to compilers writing to stderr even when nothing is wrong and therefore messing with the expected output matching. Should be all fixed now. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Major.Minor version install directories
Hello,
My install prefix currently looks something like this:
l -1 /home/stephen/dev/prefix/qtbase/kde/doc/
cmake-2.8/
cmake-2.8.12.20131023-g07324-dirty/
cmake-2.8.12.20131023-g10e02-dirty/
cmake-2.8.12.20131023-g1bfc2/
cmake-2.8.12.20131023-g3dec3/
cmake-2.8.12.20131023-g5a601/
cmake-2.8.12.20131023-g85363/
cmake-2.8.12.20131023-g8b987/
cmake-2.8.12.20131023-g8c74f-dirty/
cmake-2.8.12.20131023-gb98eb/
cmake-2.8.12.20131023-gd050b/
cmake-2.8.12.20131023-gf2f63-dirty/
cmake-2.8.12.20131024-g09257/
cmake-2.8.12.20131024-g09257-dirty/
cmake-2.8.12.20131024-g42ee2/
cmake-2.8.12.20131024-gabca/
cmake-2.8.12.20131024-ge6df9/
with similar stuff in other places in the prefix, and in other prefixes.
Can we switch those install directories back to using
set(CMAKE_DATA_DIR_DEFAULT
share/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR})
etc?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review request: Qt-auto-generators
On Thursday 24 October 2013, Stephen Kelly wrote: Hi, I've pushed the Qt-auto-generators topic to stage. This topic was discussed here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7936 I have tested it with ports of KDE Frameworks and GammaRay to use the features. Alex, could you also review the topic please? Looks good in general. Just some nitpicking: this is still Qt-specific, so I would prefer to have something related to Qt in the names of the target properties and output and maybe also if the generated files instead of AUTOGEN_TARGETS_FOLDER, AUTOGEN: and and AutogenInfo.cmake. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review request: Qt-auto-generators
Alexander Neundorf wrote: On Thursday 24 October 2013, Stephen Kelly wrote: Hi, I've pushed the Qt-auto-generators topic to stage. This topic was discussed here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7936 I have tested it with ports of KDE Frameworks and GammaRay to use the features. Alex, could you also review the topic please? Looks good in general. Just some nitpicking: this is still Qt-specific, so I would prefer to have something related to Qt in the names of the target properties and output and maybe also if the generated files instead of AUTOGEN_TARGETS_FOLDER, AUTOGEN: and and AutogenInfo.cmake. I thought about that but couldn't think of better, more suitable names. Also, just because it's Qt-specific now doesn't mean it always will be. If there's a reason for something similar relating to another tool, another rename would be needed. I'd prefer to stick with Autogen*. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Perforce Patch for CTest
On 10/24/2013 03:57 PM, Pedro Navarro wrote: That's right, p4 usually doesn't create a .p4 file I think it is fine for the test to not place .p4 files since that is representative of real use cases. Ideally each VCS implementation could have a way to tell CTest if a directory it's under that specific VCS control or not, that way we could execute whatever p4 commands we wanted inside cmCTestP4 and return true if the source directory is being managed by p4. I think that would be a great way to refactor DetectVCS. It would avoid putting VCS-tool-specific knowledge (the directory name) in the main class. The existing classes for other tools would just look for its control directory and P4 could run the tool. Thanks, -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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
