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'.
The <OBJECT_DIR> placeholder is supposed to be the base intermediate
files directory for the current target. This is how it gets replaced
during link line generation. However, during compile line generation
we replace it with the directory containing the current object file
which may be a subdirectory. Fix replacement of <OBJECT_DIR> in the
generated compile lines to be the base intermediate files directory.
This was expoxed by commit 42ba1b08 (VS: Separate compiler and linker
PDB files, 2013-04-05) when we added a "/Fd<OBJECT_DIR>/" flag to the
MSVC compile line in order to match the VS IDE default compiler program
database location in the intermediate files directory. For source files
in a subdirectory relative to the current target this caused the wrong
location to be used for the compiler program database. This becomes
particularly important when using precompiled headers.
While at it, use the cmTarget::GetSupportDirectory method to compute the
intermediate files directory for the current target instead of repeating
the logic in a few places.
Since commit 42ba1b08 (VS: Separate compiler and linker PDB files,
2013-04-05) the VS generators no longer add ProgramDataBaseFileName.
Therefore we should allow projects to do so by mapping the /Fd option.
For VS >= 10 our flag tables map /Fd to ProgramDataBaseFileName already.
Add the mapping for VS 7, 8, and 9.
In commit 18412153 (Refactor cmTarget::GetCompileDefinitions...,
2013-06-06) cmQtAutomoc was refactored to get all compile definitions
from the target instead of separately asking the target and querying the
directory-level COMPILE_DEFINITIONS property value. While the
generation process does integrate directory-level COMPILE_DEFINITIONS
into the target definitions, this did not happen until after Automoc
targets are constructed. Therefore the commit regressed use of
directory-level definitions in Automoc targets.
Factor the definition finalization logic out from the
cmGlobalGenerator::CreateGeneratorTargets method into a new
cmGlobalGenerator::FinalizeTargetCompileDefinitions method and call it
before constructing Automoc targets. This will place the
directory-level definitions into the target in time to use them for the
Automoc targets.
Extend the QtAutomoc test to cover this case.
In the CMake interactive dialogs cmGlobalGenerator::Configure may
run more than once. Clear the cmGlobalGenerator::EvaluationFiles
data between configures to avoid accessing deleted data.
Since cmTarget::ComputeLinkInterface is called separately for each
"head" target that links a target, the warning we produce when
CMP0022 is not set could be repeated. Add explicit logic to allow
the warning to appear at most once. Multiple copies of the warning
for the same target are almost always identical and therefore
redundant. In the rare case that two copies of the warning are
different, the second can appear in a future run after the first
is fixed.
When cmExportFileGenerator::SetImportLinkInterface exports the old
LINK_INTERFACE_LIBRARIES property values it skips doing so for
non-linkable targets because target->GetLinkInterface returns NULL for
such targets.
Since cmExportFileGenerator::PopulateInterfaceLinkLibrariesProperty
looks at the INTERFACE_LINK_LIBRARIES property directly instead of using
the computed link interface, teach it to skip exporting the property if
target->IsLinkable returns false.
Extend the RunCMake.CMP0022 test with a case covering this. Simply
export an executable target that links to a library that is not
exported.
The CMP0022 NEW behavior is that the INTERFACE_LINK_LIBRARIES property
exactly defines the link interface. The plain target_link_libraries
signature says linking is transitive by default, so it should populate
the property.
Teach the target_link_libraries plain signature to populate the
INTERFACE_LINK_LIBRARIES regardless of the CMP0022 setting. Refactor
the cmTarget::ComputeLinkInterface checks that warn when the policy is
not set to compare the new property to either the explicitly set old
link interface properties or the link implementation fallback for all
linkable target types, not just static libraries.
This fixes a regression in 2.8.12.0 that caused target_link_libraries to
not implement transitive linking in the plain signature once the policy
CMP0022 is set to NEW.
Teach cmGlobalGenerator::CheckTargets to include OBJECT_LIBRARY targets
in the check for source file existence.
Extend the RunCMake.ObjectLibrary test to cover this case.
Teach the cmGeneratorExpressionEvaluator filesystem artifact logic
to reject OBJECT_LIBRARY targets since they have no main artifact.
Without the explicit rejection evaluation falls through to an
internal CMake error message in cmTarget::GetOutputInfo.
Extend the RunCMake.GeneratorExpression test to cover these cases.
Only valid target names or generator expressions may appear in
the target field of a LINK_ONLY expression.
Other content like link flags should still be added to that property
(wrapped in config-specific generator expressions), but not wrapped
in LINK_ONLY. Otherwise undue warnings would be issued for the
policy CMP0022.
The LINK_ONLY expression only has an effect for actual target
names anyway, so there is no logical deficit.
Other warnings for the same policy already have similar output since
commit 81d2793e (Add differing target property content to policy CMP0022
warning, 2013-09-11).
Re-insert the semicolon which was removed during splitting.
Commit d777b8e7 (Genex: Allow relative paths in INSTALL_INTERFACE.,
2013-07-25) introduced the prefixItems method to allow relative paths
in the argument of the INSTALL_INTERFACE expression. That method was
buggy in that it did not re-introduce the semicolon separator in
the result.
This bug also affects paths which are already absolute in user code.
Xcode 2.1 through 4 supported $(CURRENT_ARCH) in a PBXFileReference
'path' value used in the "Link Binary with Libraries" build phase.
CMake uses this to reference object file locations on link lines to
bring in OBJECT library content. However, Xcode 5 now evaluates the
$(CURRENT_ARCH) reference in this context as "undefined_arch" so the
wrong path is given to the linker. There seems to be no alternative way
to produce an architecture-specific value in a PBXFileReference.
Fortunately Xcode 5 now also handles link dependencies for paths linked
through OTHER_LDFLAGS. For Xcode >= 5, move the OBJECT library object
file references from the link build phase to OTHER_LDFLAGS. We can
still show the object files in the source group listing in either case.
Xcode 5.0 now computes dependencies from files linked through
OTHER_LDFLAGS, so we no longer need the XCODE_DEPEND_HELPER hack to
re-link dependents when targets change.
In buggy code like
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h
MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/out.h.in
...)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h
...)
that has more than one rule to generate the same output CMake has always
used the first rule. However, since commit 2268c41a (Optimize custom
command full-path dependency lookup, 2013-08-06) we update the map from
output to cmSourceFile for every rule generating an output, effectively
keeping the last command instead of the first.
Fix this regression by checking for each map update if the output
already has an entry. If so, keep only the original entry. The VS 8
generator triggers this with a special case for generate.stamp rules
that differ between ZERO_CHECK and normal targets, so do not warn for
now. Leave a TODO comment for warning in the future.
Brad King
Ruslan Baratov
Stephen Kelly
Modestas Vainius
Kitware Robot