GitLab

8aa4d51e ExternalProject: Add missing release note for git update strategy
12365905 FetchContent: Pass through CMAKE_EP_GIT_REMOTE_UPDATE_STRATEGY if set
e71c2807

 ExternalProject: Remote checkout needs to include the remote name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4818

ed6d20dd

 CTest: Handle non-coverage lines in gcov files
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4822

650c1029

 CUDA: Detect non-working user-specified architectures on NVCC
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4814

90285836 Merge branch 'backport-3.16-pch-fix-bad-ClearSourcesCache'
fa7b041e

 PCH: Fix logic error that incorrectly clears sources during VS generation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4815

90285836 Merge branch 'backport-3.16-pch-fix-bad-ClearSourcesCache'
fa7b041e

 PCH: Fix logic error that incorrectly clears sources during VS generation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4815

6fc4bfa1

 Ninja Multi-Config: Fix bug in CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Reinking <alex_reinking@berkeley.edu>
Merge-request: !4825

6fc4bfa1

 Ninja Multi-Config: Fix bug in CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Reinking <alex_reinking@berkeley.edu>
Merge-request: !4825

Fixes: #20775

0eebd0a0

 gitlab-ci: pin macOS and Windows jobs to nonconcurrent runners
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Robert Maynard <robert.maynard@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !4823

This release note was mistakenly omitted from commit 0aea435a
(ExternalProject: Provide choice of git update strategies, 2020-02-12).

This was missed when the initial support was added in
commit 0aea435a (ExternalProject: Provide choice of
git update strategies, 2020-02-12)

Commit 0aea435a (ExternalProject: Provide choice of
git update strategies, 2020-02-12) added the git update
strategies, but the CHECKOUT strategy was not handling
remote refs correctly. The local ref would be checked out
instead and no warning or error would have been emitted.
The test that should have caught this was also malformed
and did not actually move the local master branch as intended.

Extend the improved error message added for Clang by commit 19cc5bc2
(CUDA: Throw error if user-specified architectures don't work,
2020-05-26) to cover NVCC as well.

Also fix the error incorrectly being thrown if the user-specified list
differed in order to the architectures parsed from the compiler output.

Implements: #20757

On macOS and Windows, our jobs use a `GIT_CLONE_PATH` that does not
contain `$CI_CONCURRENCY_ID` so that the build and test jobs always use
the same path.  Since we use shell runners for these platforms, all
concurrent jobs would use the same path and conflict.  Therefore we can
only use runners with a concurrency level of 1 for jobs in the `build`
and `test` stages.  However, jobs in the `test-ext` stage configure a
new build tree for the tests and therefore can use `$CI_CONCURRENCY_ID`
and support shell runners with higher concurrency levels.

Prepare to make that distinction in the future by pinning all jobs to
runners with a `nonconcurrent` tag.

0508a80c

 gitlab-ci: update macOS jobs to Xcode 11.5
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !4821

This implements a TODO in gcov file handling.

0d5a1fd6

 gitlab-ci: pin windows and macos jobs to runners with matching toolsets
Acked-by: Kitware Robot <kwrobot@kitware.com>
Reviewed-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !4817

5058fb54

 VS: Drop StdOutEncoding with VS 16.6 pending investigation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4820

The `StdOutEncoding` added to `.vcxproj` files since commit bc877a7e
(Add support to indicate UTF-8 custom command pipe output encoding,
2020-04-08) breaks custom commands with symbolic outputs on VS 16.6.0.
Disable it pending further investigation and possibly a fix in VS.

Issue: #20769

The toolsets available on machines hosting shell runners will evolve
over time.  Require the runners to have tags indicating that they have
specific toolsets available.  When toolsets are eventually removed from
a runner, its tags can then be updated accordingly to prevent pipelines
created for old commits from ever running on them.

1eca5993

 ALIAS target: cannot overwrite an existing target
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4810

d606b19f

 server-mode: Fix regression in cache entry reporting
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4808

2c0db404

 FindSubversion: Do not accept macOS stub without Xcode implementation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4813

2c0db404

 FindSubversion: Do not accept macOS stub without Xcode implementation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4813

Merge-request: !4815

Since commit 729d997f (Precompile Headers: Add REUSE_FROM signature,
2019-08-30, v3.16.0-rc1~101^2), `GetPchFileObject` handles the case that
it is called first for another target's `REUSE_FROM` by calling
`AddSource` to make sure `GetObjectName` can produce the correct object
name.  However, `AddSource` causes `ClearSourcesCache` to be called,
which since commit a9f4f58f (cmGeneratorTarget: Clear AllConfigSources
in ClearSourcesCache, 2020-05-15, v3.16.7~2^2) now correctly erases the
`AllConfigSources` structure.  This is okay during `AddPchDependencies`,
but there is another code path in which it is problematic.

When the Visual Studio generator's `WriteAllSources` method is looping
over the sources, the `cmake_pch.cxx` source is encountered first.  This
causes `OutputSourceSpecificFlags` to call `GetPchCreateCompileOptions`,
which calls `GetPchFile`, which under MSVC with `CMAKE_LINK_PCH` calls
`GetPchFileObject`.  That leads to `ClearSourcesCache` erasing the
structure over which `WriteAllSources` is iterating!

This bug is caught by our `RunCMake.PrecompileHeaders` test when run
with the VS generator as of the commit that exposed it by fixing
`ClearSourcesCache`.  However, that change was backported to the CMake
3.16 series after testing only with later versions versions that contain
commit a55df204 (Multi-Ninja: Add precompile headers support,
2020-01-10, v3.17.0-rc1~136^2).  By adding proper multi-config support
for PCH, that commit taught `cmLocalGenerator::AddPchDependencies` to
call `GetPchFile` with the real set of configurations instead of just
the empty string.  This allows the `GetPchFile` cache of PCH sources to
be populated up front so that the later calls to it in the
`WriteAllSources` loop as described above do not actually call
`GetPchFileObject` or `ClearSourcesCache`.  That hid the problem.

Fix this by re-ordering calls to `AddPchDependencies` to handle
`REUSE_FROM` targets only after the targets whose PCH they re-use.
Remove the now-unnecessary call to `AddSource` from `GetPchFileObject`
so that `ClearSourcesCache` is never called during `WriteAllSources`.
Update the PchReuseFrom test case to cover an ordering of targets that
causes generators to encounter a `REUSE_FROM` target before the target
whose PCH it re-uses.

Fixes: #20770