The default target in XCode is the first one in the file.
In commit v3.1.0-rc1~286^2 (cmTarget: use a hash_map for cmTargets
typedef, 2014-06-10) the order of the targets stored in cmMakefile was
made non-deterministic instead of lexicographic. Teach the Xcode
generator to do its own sorting to restore a predictable order.
While at it, place ALL_BUILD first (as is done in VS IDE generators)
explicitly in the comparison function so that it is the default target
even if other targets sort earlier lexicographically (e.g. "AAA").
In commit v3.1.0-rc1~687^2~4 (cmTarget: Make the source files depend on
the config, 2014-02-13) an early termination case was added to the Xcode
generator. Fix handling of this case to actually abort all the
generation steps. Otherwise some of the later steps are attempted
without the preconditions normally established by earlier steps,
possibly leading to a crash.
Move handling of an empty toolset name into the implementation of the
method. This simplifies the VS 10 implementation of default toolset
selection because it has one code path that is always called.
Xcode requires a separate PBXFileReference for each target source group
that references a source file. Xcode 6 now diagnoses re-use of the same
PBXFileReference from multiple source groups. Add the referencing
target name to our internal map key so we use a per-target reference.
Xcode 6 introduced an 'OTHER_LIBTOOLFLAGS' setting for the "Other
Librarian Flags" of a static library. Now 'OTHER_LDFLAGS' are ignored.
Teach the Xcode generator to choose the correct name for the build
setting based on the type of target and the version of Xcode.
Inspired-by: Jamie Kirkpatrick <jkp@spotify.com>
Many of the 'head' arguments added by commit v2.8.11~289^2~1 (Make
linking APIs aware of 'head' target, 2013-01-04) turned out not to be
needed. The "link implementation" of a target never needs to be
computed with anything but itself as the 'head' target (except for
CMP0022 OLD behavior because then it is the link interface).
Remove the unused 'head' target paths. Add "internal" versions of
cmTarget::GetDirectLinkLibraries and GetLinkImplementationLibraries
to support the CMP0022 OLD behavior without otherwise exposing the
'head' target option of these methods.
In commit 84fdc992 (stringapi: Pass configuration names as strings,
2014-02-09) a few code paths for the Xcode 1.5 single-configuration
generator were not updated to use an empty configuration name instead of
a NULL pointer when no configuration is specified in CMAKE_BUILD_TYPE.
Fix them now.
Delay use of CMAKE_GENERATOR_TOOLSET until the CMakeSystem.cmake
file has been configured and loaded during the first project() or
enable_language() command. This gives the toolchain file named by
CMAKE_TOOLCHAIN_FILE a chance to set CMAKE_GENERATOR_TOOLSET. This
point is still early enough to set the generator toolset prior to
the initialization of any languages that might use the toolset.
The cmake::GeneratorToolset member variable remains an indication
of what was specified by the -T option or loaded from the cache.
It does not need to be updated based on the toolchain file setting.
The cmMakefile::TryCompile can still pass cmake::GeneratorToolset
into the inner instance because the try-compiled project will do
platform and language initialization using the CMakeSystem module
configured for the outer project.
Extend the RunCMake.GeneratorToolset test with cases that use a
toolchain file to set CMAKE_GENERATOR_TOOLSET.
Add source file properties to control Xcode file type attributes:
XCODE_EXPLICIT_FILE_TYPE => explicitFileType
XCODE_LAST_KNOWN_FILE_TYPE => lastKnownFileType
Add a RunCMake.XcodeProject test to verify generated project content.
Choose the attribute name and file type and send them through a single
attribute generation code path. Compute the file extension only when
needed. Leave the file type selection logic indented in a block so it
can be made conditional later.
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.
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.
Implement it in terms of the ComputeObjectFilenames virtual method
on the local generators.
Remove the reimplementation from the global generators which are
now all functionally identical.
Until now the cmCustomCommandGenerator was used only to compute the
command lines of a custom command. Generalize it to get the comment,
working directory, dependencies, and outputs of custom commands. Update
use in all generators to support this.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
When using link_directories() and including CMAKE_CFG_INTDIR,
one can end up with duplicate RPATHs in the binary which
install_name_tool cannot fix without corrupting the binary.
Also, the cmake_install.cmake file has been fixed to correctly
handle these generator specific variables.
Images and xib files must have 'lastKnownFileType' attribute to be
displayed correctly. If xib file has attribute 'explicitFileType' it is
displayed as raw xml. If static image has attribute 'explicitFileType'
it is displayed as question mark on storyboard.
Since commit 56831461 (Xcode: Use explicitFileType to mark source types,
2013-04-16) the Xcode generator prefers to use explicitFileType to tell
Xcode about each source file type. This works better than
lastKnownFileType for some file types, but not for "file.storyboard".
If storyboard file has attribute 'explicitFileType' it is displayed
incorrectly (as raw xml). Switch it back to 'lastKnownFileType'.
There is no need to allow EXCLUDE_* properties, because an
INTERFACE_LIBRARY has no direct build output.
IMPORTED_LINK_INTERFACE_LANGUAGES are relevant only to static
libraries.
VERSION is relevant only to the filename of direct build outputs,
which INTERFACE_LIBRARY does not have.
Ben Boeckel
Brad King
Stephen Kelly
Clinton Stimpson
Ruslan Baratov