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
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.
This results in the correct source directory being picked up in calls
with
cmake sourcedir -C settings
and in a more appropriate error message when calling
mkdir build ; cd build ; cmake -C settings
Also fix `-D` and `-U` in the same way.
95bd6317bc RPATH: Record support for $ORIGIN on various *BSD
c9b8c79271 RPATH: Record support for $ORIGIN on Haiku and Solaris
6114d85a7d RPATH: Add option for using $ORIGIN in build tree
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2456
This makes binaries independent of the build directory by not embedding
the build directory via RPATH. The tests are partially based on the
existing RuntimePath test, but with the check moved into a POST_BUILD
command such that it can be skipped when the platform lacks support.
Fixes: #18413
2cc050b53b CUDA: Add test for device linking when host linking uses threads
83c13ca44f FindThreads: Pass -pthread to CUDA compiler through -Xcompiler
cf92fd9ae9 Merge branch 'cuda-filter-device-link-items' into cuda-thread-flags
e768d96c74 CUDA: Filter out host link flags during device linking
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kelly (KT) Thompson <kgt@lanl.gov>
Merge-request: !2512
The logic added by commit v3.12.0-rc1~62^2 (cmake: Teach '-E tar' to
report errors copying data, 2018-05-16) incorrectly reports failure
in the case of ARCHIVE_WARN. Convert this case to a warning.
Fixes: #18496
Since commit v3.12.0-rc1~278^2 (CUDA: Pass more link libraries to device
linking, 2018-03-27) we consider every link item during device linking.
However, items that start in `-` may be host-specific link flags that
nvcc will not understand during device linking. Filter such items using
a white list.
In particular, this allows `-pthread` to be used for host linking while
not polluting the device link line.
Issue: #18008
