1c1c2a12 cmGeneratorTarget: Port ExpandLinkItems away from cmTarget.
c66084f5 cmGeneratorTarget: Port GetImportLinkInterface away from cmTarget.
83c29e39 cmGeneratorTarget: Port ComputeLinkImplementationLibraries away from cmTarget.
19882554 cmGeneratorTarget: Port handleSystemIncludesDep away from cmTarget.
c1f687b1 cmGeneratorTarget: Port GetLinkImplementationLibrariesInternal.
a6e1f05c cmGeneratorTarget: Port ComputeLinkInterface away from cmTarget.
654002fe cmGeneratorTarget: Port ComputeLinkInterfaceLibraries away from cmTarget.
922c8901 cmGeneratorTarget: Port GetLinkInterface away from cmTarget.
eaa5b9cb cmGeneratorTarget: Port cmTargetCollectLinkLanguages away from cmTarget.
f539da12 cmGeneratorTarget: Port GetLinkInterfaceLibraries away from cmTarget.
1c5d70f9 cmGeneratorTarget: Port processILibs away from cmTarget.
064c2488 cmComputeLinkDepends: Port some API to cmGeneratorTarget.
3e428fdc cmGeneratorTarget: Move IsImportedSharedLibWithoutSOName from cmTarget.
110fd2fb cmGeneratorTarget: Move GetOutputTargetType from cmTarget.
e7391699 cmGeneratorTarget: Move HasMacOSXRpathInstallNameDir from cmTarget.
c5718217 cmGeneratorTarget: Move HaveInstallTreeRPATH from cmTarget.
...
In the Ninja generator we run all build rules from the top of the build
tree rather than changing into each subdirectory. Therefore we convert
all paths relative to the HOME_OUTPUT directory. However, the Convert
method on cmLocalGenerator restricts relative path conversions to avoid
leaving the build tree with a "../" sequence. Therefore conversions
performed for "subdirectories" that are outside the top of the build
tree always use full paths while conversions performed for
subdirectories that are inside the top of the build tree may use
relative paths to refer to the same files.
Since Ninja always runs rules from the top of the build tree we should
convert them using only the top-level cmLocalGenerator in order to
remain consistent. Also extend the test suite with a case that fails
without this fix.
Classify .manifest sources separately, add dependencies on them, and
pass them to the MS manifest tool to merge with linker-generated
manifest files.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
The Makefile generators run tools with the current working directory set
to the subdirectory of the build tree for the each target. The Ninja
generator runs tools with the current working directory set to the top
of the build tree. Tell cmCommonTargetGenerator where the working
directory will be so it can compute proper relative paths.
57f03e59 Port some of the cmExportFileGenerator API to cmGeneratorTarget.
57ab0f70 Port cmExportBuildFileGenerator to cmGeneratorTarget.
570938cb cmExportTryCompileFileGenerator: Create cmGeneratorTargets.
ec38e4c8 Move GetFullPath to cmGeneratorTarget
dfb025bf Move GetLocationForBuild to cmGeneratorTarget.
9f2dca80 Move GetLocation to cmGeneratorTarget.
c7a8e74b Always access target location from a cmGeneratorTarget instance.
5b60eaf6 cmTarget: Restore the ImportedGetLocation method.
50b17a61 cmIncludeCommand: Populate the cmGeneratorTargets in deprecated path.
ba266858 cmTarget: Create cmGeneratorTargets before reading deprecated LOCATION.
5ab3a946 cmTarget: Inline GetLocation into deprecated callers.
496f4cd0 cmGlobalGenerator: Create cmGeneratorTargets before QtAutomoc.
de80993a cmGlobalGenerator: Create cmGeneratorTargets earlier.
611220f7 cmTarget: Use reliable test for CMP0024 and CMP0026 OLD.
bbad6ba5 cmLocalGenerator: Remove unused AddCustomCommandToCreateObject method.
e4dc83ad cmLocalGenerator: Remove unused AddBuildTargetRule method.
...
Teach the Makefile and Ninja generators to substitute for an <INCLUDES>
placeholder instead of putting -I in <FLAGS>. Update our values for
CMAKE_<LANG>_COMPILE_OBJECT,
CMAKE_<LANG>_CREATE_ASSEMBLY_SOURCE, and
CMAKE_<LANG>_CREATE_PREPROCESSED_SOURCE
to place <INCLUDES> just before <FLAGS>.
Restore call to AppendFortranFormatFlags accidentally dropped by
commit 0837538e (cmCommonTargetGenerator: Adopt GetFlags method,
2015-07-09). It was added originally by commit 6a56740e
(cmNinjaTargetGenerator: Add Fortran flag generation, 2015-07-09).
Simplify the per-source ComputeDefines implementation by getting
target-wide defines from GetDefines. Technically this changes behavior
by no-longer de-duplicating/sorting defines from both the target and the
source, but this makes it consistent with the Makefile generator. It
may also later help move target-wide defines into per-target compilation
rules.
Create a <LANG>_COMPILER_LAUNCHER target property (initialized by a
CMAKE_<LANG>_COMPILER_LAUNCHER variable) to specify a compiler launcher
tool. This will supersede the CMAKE_<LANG>_COMPILER_ARG1 approach to
using such tools. The old approach set CMAKE_<LANG>_COMPILER to the
launcher tool while the new approach leaves this variable set to the
actual compiler.
Implement this property for Makefile and Ninja generators. It cannot be
implemented for VS or Xcode generators as the IDE build tools offer no
such hooks.
Create a <LANG>_INCLUDE_WHAT_YOU_USE target property (initialized by a
CMAKE_<LANG>_INCLUDE_WHAT_YOU_USE variable) to specify an IWYU command
line to be run along with the compiler.
Our <LANG>_COMPILER and <LANG>_<TARGET_TYPE>_LINKER rule generation has
access to a specific cmTarget so the results may depend on it. Instead
generate separate rules for each target using an encoded target name.
In particular, this makes CTEST_USE_LAUNCHERS report proper target
information.
Check for CMAKE_COMPILER_IS_MINGW only after enabling a language when it
might actually be set. Previously this worked by accident because the
check for working compiler or a second language enabled would cause the
code path to be taken.
Store UsingMinGW as an instance member of cmGlobalNinjaGenerator so that
it is reset on each reconfigure. Otherwise cmake-gui cannot switch
between build trees for MinGW or non-MinGW tools.
The "/showIncludes" flag is only available with MS C and C++ compilers,
and on compilers that "simulate" them (like Intel for Windows). Fix our
logic to choose this type only for MS tools with these languages. All
other cases need to use "deps = gcc" and define DEP_FILE in the build
rule.
Custom command path normalization added in commit v3.1.0-rc1~471^2
(add_custom_command: Normalize OUTPUT and DEPENDS paths, 2014-05-28)
broke use of OBJECT_DEPENDS to bring in custom commands because the
latter paths were not normalized too. Normalize them and add a test
case.
Reported-by: Daniel v. Gerpen
A common idiom in CMake-based build systems is to have custom commands
that generate files not listed explicitly as outputs so that these
files do not have to be newer than the inputs. The file modification
times of such "byproducts" are updated only when their content changes.
Then other build rules can depend on the byproducts explicitly so that
their dependents rebuild when the content of the original byproducts
really does change.
This "undeclared byproduct" approach is necessary for Makefile, VS, and
Xcode build tools because if a byproduct were listed as an output of a
rule then the rule would always rerun when the input is newer than the
byproduct but the byproduct may never be updated.
Ninja solves this problem by offering a 'restat' feature to check
whether an output was really modified after running a rule and tracking
the fact that it is up to date separately from its timestamp. However,
Ninja also stats all dependencies up front and will only restat files
that are listed as outputs of rules with the 'restat' option enabled.
Therefore an undeclared byproduct that does not exist at the start of
the build will be considered missing and the build will fail even if
other dependencies would cause the byproduct to be available before its
dependents build.
CMake works around this limitation by adding 'phony' build rules for
custom command dependencies in the build tree that do not have any
explicit specification of what produces them. This is not optimal
because it prevents Ninja from reporting an error when an input to a
rule really is missing. A better approach is to allow projects to
explicitly specify the byproducts of their custom commands so that no
phony rules are needed for them. In order to work with the non-Ninja
generators, the byproducts must be known separately from the outputs.
Add a new "BYPRODUCTS" option to the add_custom_command and
add_custom_target commands to specify byproducts explicitly. Teach the
Ninja generator to specify byproducts as outputs of the custom commands.
In the case of POST_BUILD, PRE_LINK, and PRE_BUILD events on targets
that link, the byproducts must be specified as outputs of the link rule
that runs the commands. Activate 'restat' for such rules so that Ninja
knows it needs to check the byproducts, but not for link rules that have
no byproducts.
Brad King
Stephen Kelly
Bill Hoffman
Thomas Herz