Commit 089fe1c1 (Optimize genex evaluation for includes and
defines., 2013-02-01) introduced an optimization on DAG processing
to not reprocess properties on targets which have already been seen.
This was refactored slightly in commit 8dfdf1c7 (Fix the tests for
evaluating includes and defines., 2013-02-18), but was not extended
to cover COMPILE_OPTIONS in commit 80ca9c4b (Add COMPILE_OPTIONS target
property., 2013-05-16).
This omission causes the same performance regression in running
cmake on LLVM which 089fe1c1 fixed before, but this time for the
transitive evaluation of the COMPILE_OPTIONS property.
As CMAKE_ROOT_FIND_PATH can be a list, a new CMAKE_SYSROOT is
introduced, which is never a list.
The contents of this variable is passed to supporting compilers
as --sysroot. It is also accounted for when processing implicit
link directories reported by the compiler, and when generating
RPATH information.
Extend the signature
try_compile(RESULT_VAR <bindir> <srcfile> ...)
to allow multiple sources as
try_compile(RESULT_VAR <bindir> SOURCES <srcfile>... ...)
Process the sources to generate a CMakeLists.txt that enables all needed
languages.
Teach the TryCompile test to try cases with two sources of the same
language and of mixed languages. Teach RunCMake.try_compile to cover
error cases for the signature.
If the expression $<TARGET_PROPERTY:prop> appears in the content
of a target property, the target that prop is read from is
the 'head target' of the expression. In contexts such as evaluating
the content of a target property during generation, such
as INCLUDE_DIRECTORIES, the 'head target' is the one on which the
initial request was made.
If evaluating a generator expression which is not a target property
content, the target must be explicitly specified. Such contexts
include add_custom_command and file(GENERATE). The content might
then look like
$<TARGET_PROPERTY:tgt,prop>
However, as there is no HeadTarget set, any generator expressions
evaluated as part of reading prop from tgt which do not specify
the tgt directly report an error.
Modify the logic of the TARGET_PROPERTY generator expression so
that in such contexts, the 'head target' is set to the appropriate
target which was first encountered.
In commit 2bc22bda (Xcode: Add frameworks search paths from link
dependeny closure, 2012-12-07) we made framework search paths from the
link closure conditional on target type, skipping it on STATIC and
OBJECT library targets that do not actually link. However, the
framework search paths also influence the compile lines (-F options) so
we need them for all target types. The Makefile generator already does
this, as did the Xcode generator prior to the above-mentioned commit.
Extract upstream KWSys using the following shell commands.
$ git archive --prefix=upstream-kwsys/ d79a792e | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' dccf7725..d79a792e
Brad King (1):
d79a792e SystemTools: Fix CollapseFullPath to not erase root component
Change-Id: I25c6600a621a960738b5afc0ba73f63df0693303
Fix the wording of the documentation for CMAKE_PARENT_LIST_FILE to
clarify that it only applies to the include stack in the current
directory. Specify exactly what commands can include files instead of
saying "somehow invoke".
It is common to specify a CMAKE_TOOLCHAIN_FILE and get a warning
for using it despite it not being used.
The WarnUnusedCliUnused test relies on the warning being emitted
each time cmake is run on an existing build. That behavior is changed
by this patch to warn only on the first invokation of CMake, and not
on subsequent invokations (because the variable is in the cache with
the same value). For that test, a clean target is added which clears
the cache and cause the warning to be emitted each time.
As the Ninja generator does not support the feature needed to test
this, it is not tested with that generator.
This command is similar to add_definitions, in that it affects
the compile options of all targets which follow it. The implementation
is similar to the implementation of the include_directories command,
in that it is based on populating a COMPILE_OPTIONS directory property
and using that to initialize the same property on targets.
Unlike the include_directories command however, the add_compile_options
command does not affect previously defined targets. That is, in
the following code, foo will not be compiled with -Wall, but bar
will be:
add_library(foo ...)
add_compile_options(-Wall)
add_library(bar ...)