Fix niggly in ExternalProject that would inadvertently
create a log file of output when a command was explicitly
set to the empty string.
Also, increase the default value for showing context
around build errors to 10 lines, up from 6. Also add
the ability to customize this setting so that users
can put it back to 6 or even lower if they want, or
show more if they want.
Clang is smart enough to recognize that "*(int*)0=0" invokes undefined
behavior, warns, and produces an "undefined instruction". The message
in commit "Avoid Clang optimizer bug in testProcess-[45]" (2010-07-02)
is incorrect; this is not a Clang bug. It really is undefined
behavior. Use "*(int*)1=0" to produce a crash instead.
Move lines from commit 696a0af (Disable gcc 33 on OpenBSD because it
crashes CPack by default, 2010-06-25) further down in CMakeLists.txt so
that CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS applies. This fixes the code for
building with CMake 2.4.
-remove trailing whitespace
-fix description of CPACK_RPM_PACKAGE_SUMMARY
-fix description of CPACK_RPM_PACKAGE_VENDOR
-fix description of CPACK_RPM_PACKAGE_PROVIDES
-do not put changelog of that file to generated RPM but read it from CPACK_RPM_CHANGELOG_FILE
-add CPACK_RPM_PACKAGE_URL
-add CPACK_RPM_PACKAGE_OBSOLETES
-add CPACK_RPM_PACKAGE_SUGGESTS
-add a loop so adding more user supplied header fields is easy
Signed-off-by: Eric NOULARD <eric.noulard@gmail.com>
Clang's optimizer, as of clang version 2.8 (trunk 107463), produces the
undefined instruction 'ud2' for the code "*(int*)0=0" on OS X x86_64.
It causes our crash tests to fail because the child process exits with
an invalid instruction instead of a segmentation fault. Work around the
bug by using "*(int*)1=0" in this case.
Commits 26ea271 and c00e4ac resulted from a bad export to KWSys CVS.
They were published automatically by a robot. We constructed a fixed
history and merged in the original history to fast-forward.
Add option KWSYS_TEST_BOGUS_FAILURES that can be set by a containing
project or in the CMake cache to list tests known to fail consistently
on a buggy system.
From: Brad King <brad.king@kitware.com>
Date: Wed, 30 Jun 2010 11:25:42 -0400
Subject: [PATCH 2/2] KWSys: Optionally suppress consistent test failures
Add option KWSYS_TEST_BOGUS_FAILURES that can be set by a containing
project or in the CMake cache to list tests known to fail consistently
on a buggy system.
---
Source/kwsys/CMakeLists.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index bdf6613..bcc7a96 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -1125,5 +1125,11 @@ IF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
SET_TESTS_PROPERTIES(kwsys.testFail PROPERTIES MEASUREMENT "Some Key=Some Value")
MESSAGE(STATUS "GET_TEST_PROPERTY returned: ${wfv}")
ENDIF(COMMAND SET_TESTS_PROPERTIES AND COMMAND GET_TEST_PROPERTY AND KWSYS_STANDALONE)
+
+ # Suppress known consistent failures on buggy systems.
+ IF(KWSYS_TEST_BOGUS_FAILURES)
+ SET_TESTS_PROPERTIES(${KWSYS_TEST_BOGUS_FAILURES} PROPERTIES WILL_FAIL ON)
+ ENDIF()
+
ENDIF(BUILD_TESTING)
ENDIF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
--
1.7.0
From: Brad King <brad.king@kitware.com>
Date: Wed, 30 Jun 2010 11:23:19 -0400
Subject: [PATCH 1/2] KWSys: Use short fallback timeout for Process tests
If any of the KWSys Process tests take more than a minute or two then
something is wrong. There is no need to wait for a long default
timeout.
---
Source/kwsys/CMakeLists.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index 083629a..bdf6613 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -1097,6 +1097,7 @@ IF(KWSYS_STANDALONE OR CMake_SOURCE_DIR)
FOREACH(n 1 2 3 4 5 6 ${KWSYS_TEST_PROCESS_7})
ADD_TEST(kwsys.testProcess-${n} ${EXEC_DIR}/${KWSYS_NAMESPACE}TestProcess ${n})
KWSYS_SET_PROPERTY(TEST kwsys.testProcess-${n} PROPERTY LABELS ${KWSYS_LABELS_TEST})
+ SET_TESTS_PROPERTIES(kwsys.testProcess-${n} PROPERTIES TIMEOUT 120)
ENDFOREACH(n)
# Some Apple compilers produce bad optimizations in this source.
--
1.7.0
Look for a C/C++ compiler pair from known toolchains on some platforms.
This makes it less likely that mismatched compilers will be found.
Check only if the environment variables CC and CXX are both empty.