The context->Makefile is never NULL, but our checks for it convince
Clang scan-build that it might be NULL. Then it warns about later
unchecked uses. Drop the unnecessary checks.
Let clients do their own research on the current strength of each
hash algorithm to choose what is best for their needs.
Suggested-by: Nico Schlömer <nico.schloemer@gmail.com>
State explicitly that the PRE_LINK mode is not for targets created by
the add_custom_target command. The existing wording for PRE_BUILD being
treated as PRE_LINK by non-VS generators will now imply this restriction
for PRE_BUILD too.
Format the reStructuredText markup manually. Organize the command
options into a definition list. Use inline markup to cross-reference
related documents.
This showed up because scan-build noticed outputFull was basically
a constant. Logic should be output all valgrind output. Then output
regular test output until output limit is reached.
- sha265.c is using some C99 specific features, in particular static
array dimensions in a function parameter array (see section 6.7.5-7
of the C99 spec). A #ifndef check was in place to prevent compilation
under MSVC but it actually needed to check for C99 compliance instead.
Even still, the C99 code fails on a few compilers (PGI being one) so for
compatibility reasons, the C99 version of the function declaration is
removed entirely, leaving only the C89 version.
- CHECK_SYMBOL_EXISTS is used to determine the presense of bswap
functions from byteswap.h. Most compilers re-dedefine the bswap_N
functions as a __bswap_N function implemented by the compiler. Since
bswap_N is usually defined as a macro then it's mere presence passes
the check. Some versions of the PGI compiler though have shipped
broken headers for byteswap.h, in particular 11.3 for x64 linux
provides byteswap.h but is missing an associated bits/byteswap.h which
causes some of the bswap_N macros to be defined but broken and unusable.
The bswap_N checks have been converted to CHECK_SOURCE_COMPILES to
ensure that the bswap_N calls are actually usable and not just merely
defined.
Simply include the "Windows" platform equivalents. This will allow
-DCMAKE_SYSTEM_NAME=WindowsPhone or -DCMAKE_SYSTEM_NAME=WindowsStore to
select variants of the Windows platform while re-using most of the
platform information from "Windows".
When CMAKE_SYSTEM_NAME is set to target one of these, add
ApplicationType and ApplicationTypeRevision elements to the .vcxproj
file used to identify the compiler so that the WindowsPhone or
WindowsStore toolchains can work.
Co-Author: Brad King <brad.king@kitware.com>
Teach the VS >= 10 generators to recognize these system names and select
the appropriate default toolset for the system version. Report an error
when the version is not known to be supported by VS.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Add boolean members to the VS >= 10 global generator to save
whether CMAKE_SYSTEM_NAME is WindowsPhone or WindowsStore
without having to repeat a string comparison.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Append %(IgnoreSpecificDefaultLibraries) to any user-specified
libraries so that the system-default list of libraries to ignore
is honored even when the user specifies more.
Brad King
Kitware Robot
Bill Hoffman
Nate Eldredge
Chuck Atkins
Daniele E. Domenichelli
Gilles Khouzam
Paul Annetts