This means for example, that consumers can use:
target_link_libraries(foo ${QT_QTGUI_LIBRARIES})
instead of also needing to specify all 'public' dependencies:
target_link_libraries(foo ${QT_QTGUI_LIBRARIES} ${QT_QTCORE_LIBRARIES} )
when using the IMPORTED targets. Also populate the
IMPORTED_LINK_DEPENDENT_LIBRARIES property so CMake can help the linker
find shared library dependencies.
Since commit 9a6ff950 (Fix for bug where VS2010 did not use .obj files as
part of the build, 2011-04-01) and commit b291d9e7 (VS10: Fix external
objects generated outside target, 2012-03-19) we try to detect whether an
external object file is also a custom command output in the same target.
This is because VS10 includes .obj custom command outputs on the link line
by default.
VS 11 supports a "<LinkObjects ...>false</LinkObjects>" setting in custom
command rules to tell VS not to link the outputs. From the VS help:
Specify whether the Inputs and output files with specific extensions (.obj,
.lib, .res, .rsc) are passed to the linker.
Treat all external object files the same and add "<Object>" settings for them.
The member variable is checked to determine whether to call
HandleMissingTarget(). As that could be called during the loop in
the comming commits, ensure that it contains all targets being
exported.
Constructs such as these are an error as they are direct self-references:
set_property(TARGET foo APPEND PROPERTY
INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
set_property(TARGET foo APPEND PROPERTY
INCLUDE_DIRECTORIES $<TARGET_PROPERTY:INCLUDE_DIRECTORIES>)
However, this is an indirect self-reference in a cycle, and not an error:
set_property(TARGET foo APPEND PROPERTY
INCLUDE_DIRECTORIES $<TARGET_PROPERTY:bar,INCLUDE_DIRECTORIES>)
set_property(TARGET bar APPEND PROPERTY
INCLUDE_DIRECTORIES $<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>)
The TARGET_NAME expression, which requires a literal, provides
target names. $<TARGET_PROPERTY:tgt,prop> also provides target
names in the cases where tgt is a literal, so that TARGET_NAME is
not needed then in addition.
This is for specifying INCLUDE_DIRECTORIES relevant to the build-location
or the install location for example:
set_property(TARGET foo PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
"$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>"
"$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include>"
)
A 'bar' target can then use:
set_property(TARGET bar PROPERTY
INCLUDE_DIRECTORIES
"$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>"
)
and it will work whether foo is in the same project, or an imported target
from an installation location, or an imported target from a build location
generated by the export() command.
Because the generator expressions are only evaluated at build-time, these
new expressions are equivalent to the ZeroNode and OneNode.
The GeneratorExpression test is split into parts. Some shells can't run
the custom command as it is getting too long.
Xcode and VS <= 7.1 will not build targets that have no source files
besides $<TARGET_OBJECTS:...>. Suggest in the documentation that
projects always add at least one real source file.
0941d62 Add a way to print the origins of used include directories.
18a3195 Keep track of INCLUDE_DIRECTORIES as a vector of structs.
76ea420 Use cmsys::auto_ptr to manage cmCompiledGeneratorExpressions
Resolve this warning:
".../Tests/CMakeCommands/target_link_libraries/depB.cpp", line 8: warning:
variable "a" was declared but never referenced
DepA a;
^
Add a test that verifies that when ctest -j 4 is called, at most, 4 tests
are executed at any one time.
The test works by running the same script as each of 100 tests. And then setting
up test properties for DEPENDS, RUN_SERIAL, PROCESSORS and COST in order to get
the tests to run in a semi-deterministic ordering, even in parallel. The script
writes a file, sleeps for a bit, and then deletes the file. In the meantime, it
counts files that currently exist, and emits output that triggers a test failure
if the count of files is ever greater than 4.
Prior to the commit that fixed bug #12904, this would result in a failed test
because the output of some of the tests would indicate that more than 4 tests
were running simultaneously.
Now that this issue is resolved, this test will help guarantee that it stays
resolved moving forward.