Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
"argument unused during compilation" -- well, thanks, but ...
If somebody has a fix to eliminate this warning entirely, rather
than simply suppressing it from our dashboard results, I'm all
ears.
The clang and icc compilers see two lines of warning with
essentially the same message. But the second line does not
say qglobal.h, so remove that part of the warning exclusion
regex. See parent commit for further comments regarding this
warning exclusion.
Qt 4.7 and earlier produce a "This version of Mac OS X is unsupported"
warning on Lion, even though they work fine once built. We'll upgrade
this machine to use Qt 4.8 when it's officially released. Until then,
suppress this warning so that we don't miss other "more real" warnings
on the dashboard.
The warning appears everywhere we use static_cast to explicitly truncate
an integer width. It appears in the form
cc-3968 CC: WARNING File = ..., Line = ...
implicit conversion of a 64-bit integral type to a smaller
integral type (potential portability problem)
static_cast<...>(...);
^
which is strange because a "static_cast" is not implicit. It also
appears in system library code.
We've chosen to drop our default dependence on xmlrpc. Thus we disable
the corresponding CTest submission method and remove the sources for
building xmlrpc locally. Users can re-enable the method by setting the
CTEST_USE_XMLRPC option to use a system-installed xmlrpc library.
This warning appears for libtar.obj, curltest.obj, and synch_client.obj
regularly on CMake dashboard submissions from VS builds. They seem to
occur due to some kind of race condition for objects in small targets.
There is nothing wrong with the code, so this just suppresses the
warnings.
