5cdd774d51 VS: Handle build target correct for .NET SDK style projects with Any CPU
309191052c VS: Set Visual Studio versions read out from solution file
f7791698cb VS: Allow setting output directory in .NET SDK style projects
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6944
* Extend Visual Studio solution parser for reading build target
* Map solution build target to project build target (especially for Any CPU)
* Use C++ <optional> template instead of pointer return value for cmSlnData::GetProjectByGUID
This was accidentally left out of commit 736663deed (Begin 3.23 release
versioning, 2022-02-03). The step is documented as part of the release
branching process in the CMake Maintainer Guide `Help/dev/maint.rst`.
Avoid looking up the PCH create/use flags just to map them through
flag tables back to the `.vcxproj` settings. Instead, simply
generate the PCH settings directly for each source file.
Since commit 9df1f33c9a (VisualStudio: move PCH rules to projects when
possible., 2020-10-15, v3.20.0-rc1~638^2) we already do this for the
target-wide PCH settings.
Commit 14d8a276 (CUDA: Support nvcc 11.5 new -arch=all|all-major flags,
2021-08-17) added all and all-major options to CUDA_ARCHITECTURES. These are
fairly generic and likely to see real-world use by distributors. Thus it's
desirable to support these also for Clang and older NVCC versions.
The supported architectures are dependent on the toolkit version. We determine
the toolkit version prior to compiler detection. For NVCC we get the version
from the vendor identification output, but for Clang we need to invoke NVCC
separately.
The architecture information is mostly based on the Wikipedia list with the
earliest supported version being CUDA 7.0. This could be documented and
expanded in the future to allow projects to query CUDA toolkit version and
architecture information.
For Clang we additionally constrain based on its support.
Additionally the architecture mismatch detection logic is fixed, improved and
updated for generic support:
* Commit 01428c55 (CUDA: Fail fast if CMAKE_CUDA_ARCHITECTURES doesn't work
during detection, 2020-08-29) enabled CMAKE_CUDA_COMPILER_ID_REQUIRE_SUCCESS
if CMAKE_CUDA_ARCHITECTURES is specified. This results in
CMakeDetermineCompilerID.cmake printing the compiler error and our code for
presenting the mismatch in a user-friendly way being useless. The custom
logic seems preferable so go back to not enabling it.
* Commit 14d8a276 (CUDA: Support nvcc 11.5 new -arch=all|all-major flags,
2021-08-17) tried to support CMP0054 but forgot to add x to the interpolated
result. Thus the conditions would always evaluate to false. This is fixed as
a byproduct of removing NVIDIA specific checks, improving the error message
and replacing architectures_mode with a simpler architectures_explicit.
Visual Studio support omits testing the flags during detection due to
complexities in determining the toolkit version when using it.
A long-term proper implementation would be #23161.
Implements #22860.
When support for `DOTNET_SDK` was added, only a minimal set of options
were built in. Based on user feedback, support for reference to dlls
(not just projects) is needed. That support is added here.
Fixes: #23166
f3ad061858 Add usage requirements to update direct link dependencies
193a999cd5 cmTarget: Add INTERFACE_LINK_LIBRARIES_DIRECT{,_EXCLUDE} backtrace storage
22d5427aa6 cmGeneratorTarget: Add LookupLinkItem option to consider own target name
f3d2eab36a cmGeneratorTarget: Fix link interface caching of partial results
d75ab9d066 cmGeneratorTarget: Clarify CMP0022 logic in ComputeLinkInterfaceLibraries
f3e9e03fe0 cmGeneratorTarget: Simplify CMP0022 warning check
216aa14997 cmGeneratorTarget: Return early from ExpandLinkItems with no items
1bc98371d1 Tests: Remove unnecessary policy setting from ObjectLibrary test
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6886
Link line construction starts with `LINK_LIBRARIES` and appends
dependencies from the transitive closure of `INTERFACE_LINK_LIBRARIES`.
Only the entries of `LINK_LIBRARIES` are considered direct link
dependencies. In some advanced use cases, particularly involving static
libraries and static plugins, usage requirements need to update the list
of direct link dependencies. This may mean adding new items, removing
existing items, or both.
Add target properties to encode these usage requirements:
* INTERFACE_LINK_LIBRARIES_DIRECT
* INTERFACE_LINK_LIBRARIES_DIRECT_EXCLUDE
Fixes: #22496
`GetLinkInterface` and `GetLinkInterfaceLibraries` cache their results
to avoid repeating work. In the case that the result does not depend on
the "head" target, they re-use results computed from the first call with
any "head" target. However, if `GetLinkInterfaceLibraries` is called
first, then not all of the link interface is populated. If
`GetLinkInterface` is later called, it needs to finish populating the
link interface even if a partially completed interface was cached.
Follow up commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces
from INTERFACE_LINK_LIBRARIES, 2021-12-15), which made the logic a bit
more complicated due to having backtraces for CMP0022 NEW behavior.
Since commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces from
INTERFACE_LINK_LIBRARIES, 2021-12-15) we can use the special storage of
the property directly.
On platforms using `CMAKE_LINK_PCH`, the implementation of
`PRECOMPILE_HEADERS_REUSE_FROM`, when re-using the PCH from one object
library in another, adds a PCH object file to the link interface.
Clear any cached link interface to ensure it is used.
The only purpose of `cmLinkImplItem`'s `FromGenex` member is to decide
whether to check CMP0027. That won't be needed for link items added by
new interfaces in the future. Clarify the name to indicate that we do
not always need to know if the item came from a generator expression.
In some cases the shortened path may end up working in practice, even if
it is over CMAKE_OBJECT_PATH_MAX, where the original path does not.
If the original path is too long, do the MD5 substitution whenever it
makes the path shorter. Retain the warning if it is still too long.
8c1731546c Help: Add release note for IBM Open XL C/C++ compiler support
24da80b70a Utilities: Suppress warnings in third-party code with IBMClang
6da99e671c IBMClang: Add support for IBM Open XL C/C++
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6785
daf372c4d6 CUDA: Fix issuing error if default architecture detection fails
7a0d098352 CUDA: Error on empty/invalid CMAKE_CUDA_ARCHITECTURES set by user
d19273bc7b CUDA: Support all and all-major on Visual Studio
5f667d783a CUDA: Actually use reverse architecture deprecation order for Clang
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Brad King <brad.king@kitware.com>
Merge-request: !6912
GCC 12 warns:
warning: '%04d' directive output may be truncated writing between
4 and 11 bytes into a region of size 5 [-Wformat-truncation=]
The surrounding logic guarantees the formatted integer will never
be more than 4 bytes, but it doesn't hurt to use a larger buffer.
This GCC behavior is documented:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104012#c5
The %f specified extends the string(TIMESTAMP) and file(TIMESTAMP)
commands to output the timestamp with a microsecond resolution.
This convention is offered by python's datetime module.
Before, the precision was limited to seconds.
The implementation is done by extending existing cmTimestamp methods
with a `microseconds` parameter. This parameter is optional in order to
be backwards compatible. The timestamps are now received in a
cross-platform manner using libuv, since the standard C functions like
time() don't allow for sub-second precision.
This requires libuv 1.28 or higher. We already require higher than
that on Windows, so update the required version for other platforms.
Implements: #19335
Brad King