When the policy was added by commit 783bce29 (Export: Disallow exported
interface includes in src/build tree, 2014-03-31) it accidentally left a
code path that would warn when the include dir is in the install tree
but *not* in the source or build tree. Fix that.
f21ac16e Replace MATCHES test on numbers with EQUAL test
7eacbaed Replace MATCHES ".+" tests with NOT STREQUAL ""
3a71d34c Use CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM where sufficient
b0b4b460 Remove .* expressions from beginning and end of MATCHES regexs
5bd48ac5 Replace string(REGEX REPLACE) with string(REPLACE) where possible
2622bc3f Clean up usage of if(... MATCHES regex) followed string(REGEX REPLACE regex)
97f2b7f5 Ninja: set correct LANGUAGE_COMPILE_FLAGS when linking
49fcffc6 Ninja: cmake formatting, make code more readable
b735c8cb MinGW: link like on Unix and use compile flags when linking
We don't do crypto here, so a "poor" random doesn't matter. In fact we have API
to allow people to get a repeatable sequence by setting a specific seed.
Replace it by cmStandardIncludes.h which drags in the proper header depending
on what the compiler provides to fix this error:
CMake/Source/cmExtraCodeLiteGenerator.cxx:27: sstream: No such file or directory
OpenBSD defines Elf64_Dyn::d_tag to be of an unsigned type, which differs from
what most other platforms do and what is the case for 32 bit. To have the tag
as unsigned makes sense, but this causes a compilation warning:
/.../CMake/Source/cmELF.cxx: In member function 'const cmELF::StringEntry* cmELFInternalImpl<Types>::GetDynamicSectionString(int) [with Types = cmELFTypes64]':
/.../CMake/Source/cmELF.cxx:945: instantiated from here
/.../CMake/Source/cmELF.cxx:668: warning: comparison between signed and unsigned integer expressions
Add an explicit typedef to cast the value to for 32 and 64 bit. That type is
unsigned and has the proper length for both platforms so no information is
lost. Explicitely cast both arguments before comparing them to avoid the
warning in all situations.
Since commit v2.6.0~388 (Added build rule variables
CMAKE_<LANG>_ARCHIVE_..., 2008-01-29) we use separate "ar cr ..." and
"ar r ..." steps to incrementally add a large list of object files to an
archive. Since the "r" command replaces existing objects of the same
name in an archive, if multiple objects have the same file name and
appear in separate append steps then one overwrites the other. Instead,
use "ar cq ..." and "ar q ..." to always append to the archive.
We already remove the archive before creating it so this will not cause
objects to be appended to existing archives on incremental rebuilds.
The matches have already been calculated and can simply be taken from
CMAKE_MATCH_n variables. This avoids multiple compilations of the same or very
similar regular expressions.
5a58efaa libarchive: Avoid using name 'u_long'
e2b02823 Update libarchive configuration within CMake
80883321 libarchive: Do not require includers to have windows.h
dfb0458e libarchive: Convert literal LL suffix to ARCHIVE_LITERAL_LL
b0a9807f libarchive: Update archive_util.c to use CMake zlib and bzip2 headers
debe4dec libarchive: Drop options not present in reduced version
66b0c4fa libarchive: Do not generate a pkg-config file
8092e759 libarchive: Update README-CMake.txt for new snapshot
2f197863 Merge branch 'libarchive-upstream' into update-libarchive
23e4666c libarchive: Disable more whitespace checks in third-party code
64713ae3 libarchive 3.1.2-218-g00f4bd83 (reduced)
Warn project developers at runtime that the module should not be used
anymore. Issue the diagnostic only when the project requires a new
enough CMake to use the alternative. Honor the
CMAKE_(ERROR|WARN)_DEPRECATED settings.
Since commit e5da9e51 (cmTarget: Allow any generator expression in
SOURCES property., 2014-03-18), source files are computed by
true evaluation of generator expressions, including TARGET_OBJECTS.
This evaluation requires the presence of cmGeneratorTarget objects
since commit bf98cc25 (Genex: Evaluate TARGET_OBJECTS as a normal
expression., 2014-02-26).
Ensure that we don't attempt to evaluate the TARGET_OBJECTS generator
expression at configure-time, as can happen if CMP0024 or CMP0026
are OLD. Use old-style parsing of the source item to extract
object target names in that case.
Avoid calling GetProperty("SOURCES") to bypass warnings from CMP0051.
Refactor existing logic in GetLanguages which is similar in intent to
the new GetSourceFiles code.
Update the logic added by commit 2f9ad7c6 (Fix FindMPI for the intel
compiler on linux, 2012-03-20) to use the implicit link directories for
the current ${lang} instead of hard-coding C or CXX which may not be
enabled. This is necessary for Fortran-only projects.
f0de3f80 CMakeDetermineVSServicePack: Add VS 11 update 4
105658df CMakeDetermineVSServicePack: Match versions more robustly
101515b9 CMakeDetermineVSServicePack: Format documentation