93c718791e VS: Use 64-bit MSBuild in VS 2022
c46b265839 VS: Add Visual Studio 17 2022 generator
b610b7a35c VS: Update v142 CL flag table for VS 17.0 Preview 1
43375c6418 Help: Remove unnecessary Sphinx versionadded markup in VS toolset selection
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6268
Visual Studio 17 2022 is now a 64-bit native application. It places the
64-bit `MSBuild.exe` in the `PATH` of VS command prompts, so prefer it
for this version and above.
This was previously attempted for older VS versions, but reverted by
commit f3cedf381e (VS: Revert "Use MSBuild matching toolset host
architecture", 2019-03-12, v3.14.0~1^2). For now, do not use the 64-bit
MSBuild for VS 16 and below.
Fixes: #18219
b0f830ced6 VS: Do not apply any '/external:*' flag table mapping on VS < 16.10
3fd65f5ca6 VS: Compare VS instance versions as strings
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6241
Since commit 887e9df0c7 (VS: Update v142 CL flag table for VS 16.10,
2021-06-04) we map several `/external:*` flags to their corresponding
`.vcxproj` elements. These elements were added to `cl.xml` in VS 16.10,
so filter them out in older VS versions. Add a field to the json flag
table format to specify the minimum version of VS needed for a given
mapping.
Issue: #22308
Since commit 9054cd05e6 (VS: Add flag table entries for '/external:W*'
flags in VS 16.10, 2021-05-28, v3.20.4~10^2) we map flags to the
`ExternalWarningLevel` element. VS 16.9 does not support that element,
but its `cl` compiler does support the `/external:W*` flags. Filter out
the flag table entry on older VS versions.
Fixes: #22308
When scanning Fortran dependencies, we know the file path at which a
provided module file is written. Store it in the `compiled-module-path`
field as specified by P1689R4. Our collator in `cmake_ninja_dyndep` no
longer needs to assume that the module file path can be derived from the
logical module name. In the future, the Fortran dependency scanning may
be done by the compiler itself, in which case it will provide the value
of `compiled-module-path`.
Read and write the `compiled-module-path` field only when explicitly
known. Move the assumption that the `compiled-module-path` can be
derived from the logical module name from the scandep parser to the
`cmake_ninja_dyndep` helper.
When running the module dependencies scan tool for for a language that
does not compile the preprocessed output, we do not actually put the
preprocessed output in the build graph. However, the value of
`CMAKE_EXPERIMENTAL_<LANG>_SCANDEP_SOURCE` may reference the placeholder
for the preprocessed source. Populate the placeholder to keep the file
out of the way. In particular, do not clobber the `.ddi` file.
Since commit 33a8e0bb09 (cmNinjaTargetGenerator: Simplify scan rule
depfile selection, 2020-11-06, v3.20.0-rc1~516^2~1), the `$out` of the
scan rule always matches our `.rsp` file selection, so use `$out.rsp`.
Use the same `cmLinkLineComputer` subclass as the generator does. This
affects the base directory from which relative paths are computed.
Fixes: #22301
e13704ce72 Add directory property to list imported targets
ea6d338ea1 cmState: Record imported target names in each directory
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6215
526e2ef71c VS: Add support for add_custom_command DEPFILE
794ad78abb Help: Generalize release note filename for add_custom_command DEPFILE
7291f31254 cmTransformDepfile: Add support for MSBuild AdditionalInputs format
a6de8ec51b cmTransformDepfile: Make directory for transformed depfile automatically
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6206
