- Number of passed/failed tests is colored according to the whole outcome
- Individual listed tested are colored according to their completion status:
* Disabled: blue
* Failed: red
* Not Run: yellow
f29e2292c9 cpack: When given an unknown generator print out all valid generators
eba7273c20 cpack: Better error message when generator doesn't exist.
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: David Cole <dlrdave@aol.com>
Merge-request: !2580
If the user does not specify a DESTINATION for a target type, the
install() command checks to see if the appropriate variable from
GNUInstallDirs is set. If it is not, then it uses an appropriate
hard-coded guess.
In addition, for FILES and DIRECTORY, the user can specify a file
type instead of a DESTINATION, and the command will use the
appropriate variable from GNUInstallDirs, or a hard-coded guess if
it is not set.
When `CMP0053` is not set to OLD or NEW then we compute both variants
in case we need to warn about a behavior change. Do not allow both
code paths to produce an uninitialized variable warning.
Fixes: #18552
Ext and External were used inconsistently in the code and the
docs. This change converts all uses of Ext to External, including
within variable names used by the generator.
Since commit v3.13.0-rc1~39^2 (add_custom_{command,target}:
WORKING_DIRECTORY generator expressions, 2018-09-22) the
`WORKING_DIRECTORY` option accepts generator expressions.
Fix support for the case of a leading generator expression
by deferring conversion to an absolute path until after
evaluation of the generator expression.
Fixes: #18543
This adds
- the variable ``CMAKE_AUTOGEN_ORIGIN_DEPENDS`` which initializes
- the target property ``AUTOGEN_ORIGIN_DEPENDS``
which controls whether or not the origin target dependencies
should be forwarded to the corresponding ``_autogen`` target.
The default value of ``CMAKE_AUTOGEN_ORIGIN_DEPENDS`` is ``ON``
which corresponds to the behavior that is in place since CMake 3.9.
Closes: #18493
With the `|| true`, a linker error before running link-what-you-use
would also use the `|| true` fragment and unconditionally succeed. Just
skip the addition since `--lwyu=` ignores the return value anyways.
Fixes#18524
bd9bfc6449 MSVC: Respect CMAKE_RC_COMPILER and CMAKE_MT in vs_link_{dll,exe}
0033676796 CUDA: Enable RC language on Windows
02f566a559 MSVC: Factor out enable_language(RC) call into helper macro
b601bb6f1c CUDA: Find CMAKE_LINKER on Windows
3eebe28ef4 cmLocalNinjaGenerator: Simplify CreateRulePlaceholderExpander
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2424
9040df31e2 Merge branch 'backport-fix-custom-target-with-csharp'
1acd1c2b50 CSharp: Fix regression in VS project type selection for custom target
a56edad6d6 CSharp: Fix regression in VS project type selection for custom target
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2549
A target created by `add_custom_target` should always be a `.vcxproj`
file even if it has `.cs` sources involved in custom commands and such.
The latter case was broken by refactoring in commit v3.12.0-rc1~160^2~7
(remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget,
2018-03-19). The reason is that the `HasLanguage` method added by
commit v3.12.0-rc1~239^2~6 (cmGeneratorTarget: add HasLanguage() as
wrapper for GetLanguages(), 2018-03-19) does not check the target type
and so is not a suitable check for deciding the project file extension.
The `HasLanguage` method was an attempt at an abstraction that turns
out not to work very well. Replace it with a dedicated `IsCSharpOnly`
method that considers the target type, sources, and non-transitive
`LINKER_LANGUAGE`.
Fixes: #18515
CMake commands vs_link_dll and vs_link_exe, performing linking on MSVC,
are responsible for calling resource compiler and manifest tool.
Before this commit, both of these tools were called directly, with the
expectation that they are available in the `PATH`. This has been fixed
by respecting CMake variables `CMAKE_RC_COMPILER` and `CMAKE_MT`
defining paths to these tools.
Fixes: #17804
