Add fields to the VS generator to select a target framework.
Migrate the existing default for VS 12 .NET CF for Windows CE.
Report the values in `CMAKE_VS_*` variables and use them for
the CSharp compiler id project too.
Issue: #22849
Explain that this represents the compiler's default and mustn't be modified
by the user. Clarify when it's used as the default.
Additionally:
* Add a reference to it in cmake-compile-features in text explaining the
feature.
* Add explanations for the default initialization by
`CMAKE_<LANG>_EXTENSIONS_DEFAULT` to all `<LANG>_EXTENSIONS` pages and
references to CMP0128.
* Slightly reduce the wordiness of the default initialization explanations by
removing an unnecessary "it is".
Fixes#22828.
Previously the `CMAKE_GENERATOR_INSTANCE` value was used only to filter
the instances reported by the Visual Studio Installer tool. If the
specified install location is not known to the VS Installer, but the
user provided a `version=` field, check for the installation directly
on disk.
Fixes: #21639, #22197
Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.
Added XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE variable which
sets the scheme property value for "GPU Frame Capture" in the Options section by setting the Xcode project variable "enableGPUFrameCaptureMode".
Example values are "Metal" (1) and "Disabled" (3).
XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE is initialized by the property CMAKE_XCODE_SCHEME_ENABLE_GPU_FRAME_CAPTURE_MODE.
Implements: #22700
02b2607a5c Help: Add release note for MCST LCC compiler support
e5d9fce03f LCC: Add dedicated support for MCST LCC compiler
2b9ef77944 CPack/DEB: deal with broken dpkg-shlibdeps on E2K architecture
0995c75301 Tests/RPM: skip tests tat rely on debugedit if it's not found
ea55ac9a51 Tests/RunCMake/CommandLine: Deal with locales that are different from English
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6608
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
1851aa49be FetchContent: Pass through networking-related CMAKE_... variables
96937438b7 Help: Clean up how TLS and NETRC variables are discussed
2a82bd85b6 Help: Add documentation for CMAKE_TLS_CAINFO
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6589
CMAKE_TLS_VERIFY, CMAKE_TLS_CAINFO, CMAKE_NETRC and
CMAKE_NETRC_FILE are now passed through to the underlying
ExternalProject sub-build. Previously, they were silently ignored.
Fixes: #22144
The changes are part of CMP0128.
When the standard level is unset:
* Flags are added if extension mode doesn't match the compiler's default.
Previously logic only worked if LANG_EXTENSIONS was ON. Fixes#22224.
* The full flag is used. Previously CMAKE_LANG_EXTENSION_COMPILE_OPTION was
used. This was only supported for IAR.
Otherwise:
* Avoid adding flags if not necessary per the detected compiler defaults.
* Fixed check for when the requested standard is older. It now matches the
nearby comments.
I reworded the fallback comment as its logic was a bit difficult to wrap my
head around.
They all had two sentences describing the same thing. Furthermore, with the
shorter wording the explicit advice to see the property being initialized for
further information seems unnecessary.
Add generic documentation to improve the discoverability of language-specific
ones and to make it possible to refer to them generically from other language
generic documentation.
Since commit bd844387df (ROCMClang: Add the ROCm toolkit derived clang
compiler to CMake, 2020-08-28, v3.21.0-rc1~66^2~6) and commit ff0d2858e1
(HIP: Extract clang compiler details from hipcc, 2020-10-21,
v3.21.0-rc1~66^2~5), the separate `ROCMClang` compiler id for `hipcc`
has caused a few problems:
* The compiler id changed from behavior of CMake 3.20 and below,
breaking projects that already built with `hipcc` treated as `Clang`.
* The implementation of `target_compile_features` was incomplete for
the `ROCMClang` identity.
* Only `hipcc` was identified as `ROCMClang`, so after it is unwrapped
to the underlying `clang++`, future runs of new CMake versions on
an existing build tree would not repeat this.
* Clang should be usable as a HIP compiler without the `hipcc` wrapper.
Remove the `ROMClang` compiler identity, and revise HIP language support
to work directly with a Clang compiler.
Reject direct `hipcc` usage as a HIP compiler. For now it cannot be
supported because it interferes with flags CMake needs to pass to Clang.
Fixes: #22536, #22460, #22593
Document in `CMAKE_<LANG>_IMPLICIT_LINK_{LIBRARIES,DIRECTORIES}` how
their value is used and that a fallback value may be provided by a
toolchain file.
0c7f918fb1 VS: Update Visual Studio 17 2022 generator for Preview 2
1ac1436b25 VS: Fix `/sourceDependencies` flag table entries for v143
919fc7fd5f VS: Remove broken EnableASAN entry from flag table for v143
3f19847b28 VS: Remove empty ExternalWarningLevel entry from flag table for v143
ccb6083cbe VS: Remove empty LanguageStandard entries from flag table for v143
c167de7e70 VS: Remove empty ConformanceMode entry from flag table for v143
993d706a17 VS: Populate `/JMC-` flag table entry for v143
a070d87e08 VS: Populate `-Qspectre-` flag table entry for v143
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Egor Pugin <egor.pugin@gmail.com>
Merge-request: !6350
Currently, this feature is only supported on ELF platforms. So, the property
LINK_WHAT_YOU_USE will be ignored for other plateforms.
Moreover, flags and commands are now controled by CMake variables.
Fixes: #20174
Extend the documentation added by commit 96a7040107 (project: Define
variables indicating whether project is top level, 2021-03-24,
v3.21.0-rc1~443^2) to give some examples of how the variables are set in
each context.
Add a `CMAKE_REQUIRE_FIND_PACKAGE_<PackageName>` variable is complement
to `CMAKE_DISABLE_FIND_PACKAGE_<PackageName>` with just the opposite
behaviour: it turns non-required find_package call into the required one.
While optional package dependencies usually result in simple and clean
build logic, sometimes people want to be sure those optional
dependencies will be found and used. Examples are reproducible builds
and build instructions for 3rd parties. People choose to make
find_package calls REQUIRED and put them behind an option(). Such
workarounds blend build logic with build environment management and do
not look elegant.
When no `CMAKE_CONFIGURATION_TYPES` is explicitly specified while
creating a new build tree, check for an environment variable of the same
name.
Issue: #20983
