Re: [cmake-developers] [Patch] Add option --no-return-code
Yeah, you are right. If ctest itself fails it should return non-zero.
We use qtestlib [1] from Qt5 and add every testsuite with ADD_TEST and dump
a logfile that will be parsed by xunit plugin [2] of jenkins.
ADD_TEST(${TESTNAME} ${TESTNAME} -platform offscreen -v2 -o
${CMAKE_CURRENT_BINARY_DIR}/results.${TESTNAME}.log.xml,xml)
The problem is that the test binaries of qtestlib will return non-zero if
some testcase is broken. So ctest will also return non-zero because a
testsuite failed.
Of course, this is the correct behaviour if something goes wrong. But if
ctest returns non-zero, jenkins will abort the whole build instead of let
xunit plugin mark the build as unstable because testcase XY failed.
Best regards
André
[1] http://doc.qt.io/qt-5/qtest-overview.html
[2] https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin
2015-08-14 16:01 GMT+02:00 Brad King brad.k...@kitware.com:
On 08/13/2015 04:09 PM, A. Klitzing wrote:
We use ctest on Jenkins in a shell build step. Jenkins will FAIL
the build if the last command (ctest) will return a non-zero
return code even the configured UNSTABLE/FAIL threshold is not
reached.
This won't be necessary if ctest could ignore the return codes.
If something goes wrong with the administration of running the
dashboard client, like git fetch fails, then CTest should report
failure via a non-zero return code. Some cleanup of this was done
recently to tolerate failed tests and such without making the process
exit code non-zero. If you've found remaining cases where normal
testing failures produce a non-zero exit from ctest then we should
fix those first.
Can you explain your case in more detail, please?
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Java support
Thank you. Unfortunately I don’t have access to an HP-UX system. From what I remember, HP-UX expect shared libraries with same name pattern as Linux except that extension is .sl rather than .so. Marc On 14/08/15 15:45, Brad King brad.k...@kitware.com wrote: On 08/07/2015 04:04 AM, CHEVRIER, Marc wrote: New version of patch attached. Thanks. Applied with a few tweaks: UseJava: Add support for javah tool http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=cae7bef9 However, it fails on some HP-UX machines because Java does not know how to load the native library we produce. Does anyone know what name HP-UX is expecting (I don't have access to it myself)? -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015703]: cmake -E copy is not working with wildcart, when full path is specified
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15703 == Reported By:gang65 Assigned To: == Project:CMake Issue ID: 15703 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-08-18 07:25 EDT Last Modified: 2015-08-18 07:25 EDT == Summary:cmake -E copy is not working with wildcart, when full path is specified Description: The copy operation is not support wildcart (star *) when the full path is specified. But it is working correctly with remove. cmake -E remove is not consistent with cmake -E copy. With using cmake shell comamnd you could add star to whole path: cmake -E remove /Users/warsaw/cos/*.h But it is not possible to make similar operation with -E copy: cmake -E copy /Users/warsaw/cos/*.h .. displays CMakre Error But: cmake -E copy *.h .. or: cmake -E copy /Users/warsaw/cos/file.h .. is working correctly. Steps to Reproduce: 1. mkdir /Users/warsaw/cos/ 2. cd /Users/warsaw/cos/ 3. touch file.h 4. cmake -E copy /Users/warsaw/cos/*.h .. displays CMakre Error Working correctly: cmake -E copy *.h .. cmake -E copy /Users/warsaw/cos/file.h .. == Issue History Date ModifiedUsername FieldChange == 2015-08-18 07:25 gang65 New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Recursion in OUTPUT_NAME genex
Please try new patch in attachment, this might fix it. I'm now using both the config name and the implib boolean for the map key. I didn't use std::tie to implement operator since I remember you told me to not use C++11 features in CMake code. Let me know if that works out. Thanks. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, August 18, 2015 10:44 AM To: Robert Goulet robert.gou...@autodesk.com Cc: cmake-developers@cmake.org Subject: Re: Recursion in OUTPUT_NAME genex On 08/17/2015 11:59 AM, Robert Goulet wrote: I'm assuming that master branch is 3.4? Yes. It's not yet in 'master' though. cmGeneratorTarget: Avoid recursion in GetOutputName method http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e66a7d69 I had to revert it due to nightly testing failures. The problem is that the output name map you created needs to have two values for each entry. The result is different for implib and !implib. Please revise. Thanks, -Brad output-name-genex-recursion-fix.patch Description: output-name-genex-recursion-fix.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Retain platform name when generating VS projects
Thanks, it does work. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday, August 18, 2015 10:44 AM To: Robert Goulet robert.gou...@autodesk.com Cc: cmake-developers@cmake.org Subject: Re: [cmake-developers] Retain platform name when generating VS projects On 08/18/2015 10:12 AM, Robert Goulet wrote: replace the Win32 or x64 string in the platform name See CMAKE_GENERATOR_PLATFORM and the cmake -A command line option. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0015597]: Issues with the 'Eclipse CDT4 - NMake Makefiles' Generator
Hello, On 29/05/15 20:56, Mantis Bug Tracker wrote: Summary:Issues with the 'Eclipse CDT4 - NMake Makefiles' Generator Description: The project compiles and links in Eclipse but the preprocessor symbols are not defined by the .cproject file. As a result, sections with I also stumbled upon this problem and pushed a topic containing a fix: http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/sublime-msvc-includes Could you please review and if appropriate merge to next? Thanks, Gregor -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Retain platform name when generating VS projects
Hi all, Here at the office we added some code to CMake to be able to support closed platforms when generating Visual Studio project files. The changes weren't complicated; it was just a matter to retain the platform name upon generation. Essentially, we replace the Win32 or x64 string in the platform name of the Visual Studio project, and set compile/link options from the command line flags. That is possible because the vendors of these closed platforms provide a Visual Studio integration, which work very nicely. We are wondering if there's a way to do this without having to change the CMake source code? Would it be possible do achieve this from a CMake module? Or perhaps it would be a good addition to CMake? Thoughts? Thanks! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Patch] Add option --no-return-code
On 08/18/2015 04:30 AM, A. Klitzing wrote: Yeah, you are right. If ctest itself fails it should return non-zero. [snip] ctest will also return non-zero because a testsuite failed. Right, it should not do the latter. Looking through recent history the cleanup of return code computation I mentioned in an earlier response does not appear to be there. I think similar discussion previously led to the need for such cleanup but it looks like it was never actually done. The error and return code handling within CTest is fairly messy due to historical evolution and incremental expansion of the ways in which tests can be run. As a start, one could look at making ctest_test() not affect the return code just due to a test failure. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Recursion in OUTPUT_NAME genex
On 08/17/2015 11:59 AM, Robert Goulet wrote: I'm assuming that master branch is 3.4? Yes. It's not yet in 'master' though. cmGeneratorTarget: Avoid recursion in GetOutputName method http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e66a7d69 I had to revert it due to nightly testing failures. The problem is that the output name map you created needs to have two values for each entry. The result is different for implib and !implib. Please revise. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] CPack: change cpack_set_if_not_set into a function
On 08/17/2015 05:13 PM, Роман Донченко wrote: What makes this macro a public one? It's not listed in cmake --help-module CPack, so I assumed it was an implementation detail. It was originally intended as an implementation detail but since it is available in a public module, does not start in an underscore, and is not explicitly commented as internal, I expect projects may be using it. The original method is left from early days when we did not have a formal way to document such APIs. Instead one could introduce a new API function for this, e.g. cpack_maybe_set(...) Even supposing that the macro is part of the API and is thus immutable, I don't see why its replacement should be. I agree. The replacement can be named _cpack_maybe_set and commented as internal. The original can be commented as deprecated and left unused. One could even add a message(DEPRECATION) command to the original. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Retain platform name when generating VS projects
On 08/18/2015 10:12 AM, Robert Goulet wrote: replace the “Win32” or “x64” string in the platform name See CMAKE_GENERATOR_PLATFORM and the cmake -A command line option. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Clarification requested on #10126 (CMake creates files with wrong permissions)
On Sun, Aug 16, 2015 at 21:52:26 -, James Johnston wrote: d. If the answer to (c) is yes, should that keyword become the default, subject to a new policy? (And introduction of a different NO_RESPECT_UMASK keyword). FWIW, the install(1) tool does not respect umask by default (and has no option for it), so I think the default should be to ignore the umask. Having an option is fine, but it should be documented that this is non-standard behavior in terms of what most (autotools) installs do. --Ben -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting up environment using ExternalProject_Add
On 11-Aug-15 07:49, James Johnston wrote: I have found it annoyingly difficult to set up an environment for a build when using ExternalProject_Add. I can confirm that there is an additional mess with the environment sometimes and not just about setting it (like vcvarsall.bat for Visual Studio) but with *un*setting them too. In short environment variables for the ExternalProject_Add are not the same as a user's environment. I've found myself some problems with Xcode which add tons of new variables but there are even cases for Makefiles (e.g. stackoverflow.com/questions/25160405/). I will not say it's an annoying thing for me but if there will be some mechanism to control it (better globally or even something from the box) ExternalProject_Add code can be simplified. I'm personally using next patterns: CONFIGURE_COMMAND @MSVC_VCVARSALL@@MSVC_ARCH@ # Set Visual Studio environment COMMAND ... # real configure command (like bootstrap.bat or configure.bat) BUILD_COMMAND . /path/to/clear-all.sh make # run make in a clean environment INSTALL_COMMAND . /path/to/clear-all.sh make install # same for make install include(/path/to/clear-all.cmake) execute_process(COMMAND make @make_params@ ...) # run make in a clean environment Cheers, Ruslo -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
