cbf0756 Revert "Add the TARGET_DEFINED generator expression"
21a342c Remove use of TARGET_DEFINED from the target_link_libraries test.
47b8d32 Remove use of TARGET_DEFINED from the ExportImport test.
2e39d21 Remove use of TARGET_DEFINED from target_include_directories test.
Use the /STACK: flag to pass the value through flag parsing so that the
generator converts it to the StackReserveSize project file option. The
option was accidentally left out by commit 7491f529 (first pass at VS
10, 2009-06-25).
Suggested-by: goatboy160@yahoo.com
As of commit 1da75022 (Don't include generator expressions in
old-style link handling., 2012-12-23), such entries are not
included in the LinkLibraries member. Generator expressions in
LinkLibraries are not processed anyway, so port to the new way
of getting link information.
In the case of input like
foo$<1:bar>
the preGenex should be 'foo'. In that case, the search for a ';'
will not find one, and there is no preceding input to process as a
non-genex list.
Previously, the result of 'splitting' such a string would instead
be a vector containing the same string two times.
8dfdf1c Fix the tests for evaluating includes and defines.
98a6725 Fix constness of accessors.
7e70744 Expand includes and defines transitively in 'external' genexes.
d1a2729 Fix DAG checker finding cycling dependencies.
e72eaad Workaround broken code where a target has itself in its link iface.
ec2c67b Strip stray semicolons when evaluating generator expressions.
236133e Handle targets in the LINK_LIBRARIES of try_compile.
1c0597c Add a new Export generator for IMPORTED targets.
f2ab17d Keep track of all targets seen while evaluating a genex.
This reverts commit 2bee6f5ba5.
This expression is not used, and has a semantic which is not completely
optimal (namely considering utility targets to be targets, though
usually we are interested in linkable targets).
Remove it so that we have more freedom to define better expressions in
the future.
Conflicts:
Source/cmGeneratorExpressionEvaluator.cxx
Tests/CMakeCommands/target_compile_definitions/CMakeLists.txt
Tests/CMakeCommands/target_compile_definitions/consumer.cpp
This is similar in spirit to commit e48d8420 (Cache context-independent
includes on evaluation., 2013-02-03), but it is needed since commit
a1c4905f (Use the link information as a source of compile definitions
and includes., 2013-02-12), which changed how includes and defines
are determined. As they are now determined through the link interface,
we need to cache the result of evaluating them through that.
In the case of the includes, the result was already being cached
and then immediately disposed. Store the result as a member variable
instead to make use of the caching.
We should also check whether the INTERFACE_ variant of a property
is being read, and in the case of the compile definitions, we should
test the _<CONFIG> suffixed variants. That is already available
through the use of the methods.
This way, we use the ALREADY_SEEN optimization when evaluating
the includes of a target in 'external' generator expressions, ie, those
used in a add_custom_command invokation, as opposed to evaluating the
INCLUDE_DIRECTORIES of a target itself via GetIncludeDirectories.
This means that we can use expressions of the form
$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>
to get a list of the interface include directories of foo, including
those coming from dependencies.
We can't have a test of a target which has a single include directory in
its INCLUDE_DIRECTORIES because the shell on the MSYS platforms transforms
a single include directory to include a prefix, which is not what the test
expects. We test a target with two directories instead as a means to
test a target with no link dependencies.
Before this patch, the following is reported falsely as a self-reference:
target_link_libraries(empty2 LINK_PUBLIC empty3)
target_link_libraries(empty3 LINK_PUBLIC empty2)
add_custom_target(...
-DINCLUDES=$<TARGET_PROPERTY:empty2,INTERFACE_INCLUDE_DIRECTORIES>
)
The reason is that the existing code assumed that all reading of
include directories would be done through cmTarget::GetIncludeDirectories()
and would therefore be initialized with a DagChecker. That is not the case
if reading the property with an 'external' generator expression.
There is a test for this since commit 8e756d2b (Tolerate cycles in
shared library link interfaces (#12647), 2012-01-12), so make sure
it continues to pass, even as we require no self-references in new
INTERFACE_ property generator expressions.
In commit bed6c388 (VS,Xcode: Remove unused CMAKE_GENERATOR_* variables,
2013-02-19) we removed this variable among others from the VS generator
claiming they were all not used. In fact the Fortran compiler detection
module CMakeDetermineFortranCompiler.cmake uses CMAKE_GENERATOR_FC even
for the Visual Studio IDE generators because it does not use the full
IDE compiler id detection like the C and C++ language files do.
Imported targets are re-exported so that they can be used by the
try_compile generated code with target_link_libraries.
This makes the use of the cmake_expand_imported_targets macro
obsolete. The macro is not able to expand the generator expressions
which may appear in the IMPORTED_LINK_INTERFACE_LIBRARIES content.
Instead it just sees them as 'not a target'.
Previously, GetIncludeDirectories was called before calling
target->AddSourceFile(mocCppSource). Since commit a1c4905f (Use the
link information as a source of compile definitions and
includes., 2013-02-12), the include directories are determined by
the link information.
Valid link information requires that the linker language can be
determined, which depends on the source files languages and the
dependent targets languages. In the case of the no_link_languages
target in the unit test, there are no dependencies and the additional
source file no_link_languages_automoc.cpp is added to the target
at generate-time. That file can be used to determine the linker
language, but it must be added to the target before calling
GetIncludeDirectories.
Kitware Robot
Brad King
Stephen Kelly