Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.
Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.
Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.
Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
When config-specifig generator expressions are supported, a target
may have SOURCES:
src1.cpp $<$<CONFIG:Debug>:src2.cpp> $<$<CONFIG:Release>:src3.cpp>
and computation in cmTargetTraceDependencies would add each of the
src2.cpp and src3.cpp sources back to the target without a
config-guard. That would make the sources be used later when
generating the buildsystem, regardless of the configuration.
Avoid calling AddSource on the target with the result of the
GetSourceFiles call.
If CMAKE_BUILD_TYPE is set, and user code contains:
target_link_libraries(myexe prefix_$<$<CONFIG:Debug>:debug>)
then the computation with an empty config was computing a target-level
dependency on a target or library called prefix_, and a dependency
on a target or library called prefix_debug (as expected).
The existing logic skips 'prefix_' because it is not a known target,
and defers to the link-dependencies logic to find the library. The
link-dependencies logic does not incorrectly handle the config as
cmComputeTargetDepends did, and so did not encounter 'prefix_'
during its computation. This likely had no effect on the generated
buildsystem.
Add a ComputeObjectMapping method to compute the object
names. It takes mapping to populate as an out-parameter so
that it can be extended in the future with parameters
relevant to generator expression evaluation.
Remove the supporting cmGeneratorTarget::AddObject method. It is
no longer needed as the container member is populated directly.
The ComputeObjectMapping method is called whenever objects are
requested from the cmGeneratorTarget. Because the Xcode generator
makes no such request, explicitly invoke the method from that
generator so that the logic of checking for bad sources in object
libraries is executed.
In a follow-up, the UseObjectLibraries usage may be replaced by a
true generator expression evaluator for TARGET_OBJECTS. That
will require generators to use cmGeneratorTarget::GetExternalObjects
which is not currently the case for Xcode and VS generators.
Remove use of UseObjectLibraries from Makefile and Ninja generators. It
is not needed now because those generators use GetExternalObjects
which already contains the objects from object libraries.
The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects
methods. Ensure that duplicates are not created by skipping objects
from object libraries in handling of GetExternalObjects.
Similarly, fix VS6, VS7 and Xcode object handling by skipping
external objects from OBJECT_LIBRARY usage as appropriate.
The error message in the BadSourceExpression1 test is now reported
by the generator expression evaluator, so it has different text.
This will allow the strings to contain generator expressions.
At this point, generator expressions are still not part of the
SOURCES property when it is read.
693f8bf3 FindThreads: simplify checking for SunOS
858ce31f FindThreads: avoid useless checks if a thread library is already found
fdf7bd27 FindThreads: replace MATCHES with STREQUAL
Fix cmOSXBundleGenerator::CreateCFBundle to place Info.plist under the
same root directory as the rest of the bundle. Without this, Info.plist
was placed into CMAKE_BINARY_DIR, not CMAKE_CURRENT_BINARY_DIR because
the target path was not generated correctly.
Stephen Kelly
Kitware Robot
Brad King
Tim Blechmann