Xcode 1.5 writes helper scripts at the projectDirPath location for
targets that do not set SYMROOT. We now add SYMROOT to custom targets
so that all targets set it. This prevents Xcode 1.5 from touching the
source directory now that we always set projectDirPath.
See issue #8481.
Xcode project source file references need to always be relative to the
top of the source tree in order for SCM and debug symbols to work right.
We must even allow the relative paths to cross outside of the top source
or build directories.
For subdirectory project() command Xcode projects we use the source
directory containing the project() command as the top. Relative paths
are generated accordingly for each subproject.
See issue #8481.
This subclass of cmGlobalXCodeGenerator only provided two virtual method
overrides, and it made construction of the Xcode generator instance
complicated. This commit removes it and replaces the virtual methods
with tests of the Xcode version. The change removes duplicate code.
Xcode does not seem to support direct requests for using the linker for
a particular language. It always infers the linker using the languages
in the source files. When no user source files compile with target's
linker language we add one to help Xcode pick the linker.
A typical use case is when a C executable links to a C++ archive. The
executable has no C++ source files but we need to use the C++ linker.
This passes the build configuration to most GetLinkerLanguage calls. In
the future the linker language will account for targets linked in each
configuration.
This simplifies computation of the lastKnownFileType attribute for
header files in Xcode projects. We now use a fixed mapping from
header file extension to attribute value. The value is just a hint to
the Xcode editor, so computing the target linker language is overkill.
This method previously required the global generator to be passed, but
that was left from before cmTarget had its Makefile member. Now the
global generator can be retrieved automatically, so we can drop the
method argument.
Xcode 2.0 and below supported only one configuration, but 2.1 and above
support multiple configurations. In projects for the latter version we
have been generating a "global" set of buildSettings for each target in
addition to the per-configuration settings. These global settings are
not used by Xcode 2.1 and above, so we should not generate them.
The cmGlobalXCodeGenerator::CreateBuildSettings had the three arguments
productName, productType, and fileType that returned information used by only
one of the call sites. This change refactors that information into separate
methods named accordingly.
Previously we named Xcode targets using the output file name from one of the
configurations. This is not very friendly, especially because it changes with
CMAKE_BUILD_TYPE. Instead we should use the original logical target names for
the Xcode target names. This is also consistent with the way the other IDE
generators work.
CMake previously generated Xcode project files labeled as 2.4-compatible
by recent versions of Xcode (3.0 and 3.1). It is better to generate
native Xcode 3.0 and 3.1 projects. In particular, this can improve
build times by using the "Build independent targets in parallel"
feature.
Patch from Doug Gregor. See issue #9216.
Long ago the native build system generators needed HEADER_FILE_ONLY to
be set on header files to stop them from building. The modern
generators correctly handle headers without the help of this property.
This removes automatic setting of the property so that it can be used
reliably as an indicator of project author intention. It fixes VS IDE
project files to show header files normally instead of excluded (broken
by the fix for issue #7845).
Previously cmTarget::GetLocation and cmTarget::GetFullPath would return
for Mac AppBundles the top-level bundle directory but without the .app
extension. We worked around this at the call sites. This fixes the
methods and removes the work-arounds. See issue #8406.
In cmGlobalGenerator we use cmComputeTargetDepends to construct a safe,
non-circular set of inter-target dependencies. This change enables use
of the results by the Xcode generator. It also removes a lot of old
code and another use of the old-style linking logic. See issue #7652.
A Mac OS X Framework should provide a Resources/Info.plist file
containing meta-data about the framework. This change generates a
default Info.plist for frameworks and provides an interface for users to
customize it.
This change cleans up the implementation of cmXCodeObject to avoid
un-escaping and re-escaping string values. There is no need to store
the string in escaped form. It can be escaped once when it is printed
out to the generated project file.
- The Info.plist file in app bundles should not be built.
- User-specified files such as foo.txt should not be built.
- Only files with a recognized language should be built,
just as in the Makefiles generators.
- See bug #7277.
- Generated Xcode projects for application bundles list the
CMake-generated Info.plist input file as a resource.
- The location of the input file was moved by a previous commit,
but the reference to it as a resource file was not updated.
- This change moves the file to CMakeFiles/<tgt>.dir/Info.plist
to give it a more intuitive name in the Xcode project.
- We also update the reference to point at the correct location.
- See bug #7277.
- The Xcode generator creates one Info.plist input file which is
converted at build time by Xcode and placed in the final bundle.
- The <CONFIG>_OUTPUT_NAME target property can place different content
for the exe name in Info.plist on a per-configuration basis.
- Instead of generating a per-config Info.plist input file just let
Xcode put the name in at build time using the $(EXECUTABLE_NAME) var.
Brad King
Bill Hoffman
David Cole