375b420fdf CSharp: Fix regression in VS project type selection
8b21aa0af0 VS: Fix CSharp flag selection when linking to a static C++ library
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2427
Code extracted from:
https://gitlab.kitware.com/utils/kwsys.git
at commit 9d6873b11837f341027c9a6f2880708126f08b8b (master).
Upstream Shortlog
-----------------
E5ten (1):
f17f22a2 Terminal: Add alacritty and alacritty-direct to VT100 color support whitelist
Use of `std::log10` added by commit 02c5091c90 (cmCTestRunTest: Simplify
number width computation, 2018-09-08) broke our number width computation
on some platforms where
static_cast<int>(std::log10(static_cast<size_t>(10)))
somehow produces `0` instead of `1`. Re-implement the logic to avoid
floating-point computations.
A that target contains only `.cs` sources should be generated as a
`.csproj` project even if it links to non-CSharp static libraries.
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) enforces its "exclusive" check
on the combined set of source file languages and the link language.
To restore the original `TargetIsCSharpOnly` semantics, update
`HasLanguage` to enforce exclusiveness only on the list of sources.
Fixes: #18239
When a CSharp target links to a static C++ library, CMake will compute
the link language as C++ instead of CSharp. That may be incorrect and
needs further investigation, but it does not affect how VS drives C#
linking. However, it does break our flag language selection logic
and causes C++ flags to be used for CSharp. In particular, this
drops the `-platform:x86` flag on 32-bit builds.
Fix this by always selecting the CSharp flags when generating a
`.csproj` project type.
Issue: #18239
5e61b79b82 install: Set permissions on directories created by install(DIRECTORY)
fbd89b6753 Help: Add note about CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2428
The directories that are implicitly created by install(DIRECTORY)
were not having their permissions being set by
CMAKE_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS. This change refactors
cmFileCopier to take this into account for directory installation.
b3d5b8b3fb ctest: Add option for live progress summary in terminal
62fbe5002a cmCTestRunTest: Thread number of completed tests through start APIs
02c5091c90 cmCTestRunTest: Simplify number width computation
6a285bb737 cmCTestRunTest: Buffer test result output before printing
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2240
Some platforms (e.g. GNU/Hurd) do not define PATH_MAX. Add a few other
variants and a fallback constant. Also use alternatives where possible:
* For readlink(), use lstat() to read the length of the link first.
If it is not a symlink, report EINVAL before trying to allocate.
If the size reports as zero, fall back one of the PATH_MAX variants.
* For realpath(), POSIX 2008 allows us to pass a NULL buffer
to tell it to malloc() internally.
This patch was inspired by downstream patches in Debian packaging
for issues 897061 and 909011.
Issue: #18337
When running an in-source build the CustomCommandWorkingDirectory test
created a copy of a source file in the same directory it was running on.
This breaks when byproducts are cleaned (e.g. via Ninja) because it
deletes one of the source files.
22282d6931 Tests: Add VSWinStore* test for VS 2017 ARM64
57b9a072cb Tests: Teach VSWinStore* tests to pass the architecture as a parameter
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2389
