Represent the input file path internally in canonical form. Otherwise
multiple `configure_file` calls that share the same input file but specify
it relative to different directories (e.g. via `../`) result in multiple
copies of the dependency on the rule to re-run CMake. This causes the
Ninja generator to emit duplicate phony build statements for these
dependencies, which generates an error with `-w dupbuild=err`, which
will be default in Ninja 1.9.
Also canonicalize the output path for consistency.
Add a test case.
Fixes: #18584
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
Since commit v3.12.0-rc1~278^2 (CUDA: Pass more link libraries to device
linking, 2018-03-27) we consider every link library during device
linking and use `-Xnvlink` to pass those that do not end in `.a`.
However, nvlink breaks on versioned shared library names such as
`.so.1`. Work around this problem by not passing library paths that do
not end in `.a` or `.lib`. nvlink would not find device symbols in them
anyway.
Fixes: #18504
Since commit v3.10.0-rc1~391^2~3 (Add directory property 'LABELS' and
CMAKE_DIRECTORY_LABELS variable, 2017-06-23) this command was
accidentally not allowed in script mode. It was dropped because
`ctest -S` mode needs to start with CMake's normal script mode and
then replace the `set_directory_properties` implementation. Restore
the normal `set_directory_properties` in script mode and then add
special logic to replace it in ctest. Also add a test case.
Fixes: #18523
379e5f93a9 Tests: Add cases for -{C,D,U} without a source tree
5873815fef cmake: distinguish '-Cpath' from '-C path' in source dir parsing
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2517
The following was disallowed:
add_library(iface INTERFACE)
target_link_libraries(iface PUBLIC)
just due to the mention of the `PUBLIC` keyword. Instead, only error if
there are actually `PUBLIC` dependencies specified (and analogously for
other restrictions).
Update tests to expect this new behavior.
Some target types don't allow setting certain properties even if there
is no value being set there. Guard against this by avoiding property
setting when there is nothing to add.
