Changes in cmVisualStudio10TargetGenerator::Generate to write .Net
SDK-style project for VS generators VS 19 and above. Also adds
documentation and tests.
Issue: #20227
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.
de4f1f26b0 CTest: add an ENVIRONMENT_MODIFICATION property
4c757fa3c8 Help/prop_test/ENVIRONMENT: clarify the scope of the changes
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6299
This property allows projects to modify environment variables at test
time rather than trying to guess what the state should be based on what
is present at configure time. Of particular interest is the ability to
use a `PATH` present at test time while adding entries known to be
necessary for the test itself.
There are multiple operations provided to modify variables, including:
- setting and unsetting
- appending and prepending as:
- strings
- path lists
- CMake lists
Additionally, a `reset` action is provided to cancel any prior
modifications to that particular variable in the case of incremental
additions to the test property.
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.
The change in commit 901386f646 (cmake-mode.el: Add navigation by
function and macro, 2020-12-11) introduced a regression. Emacs 26 could
not load cmake-mode.el anymore. Use `(not-char ")")`, not `(not ")")`.
We're using rx in cmake-mode.el. Technically, we don't have to load the
package, because it's already loaded at startup. But it's good style to
explicitly require the packages we use, if only to give a quick overview
of the package dependencies.
Add the functions cmake-beginning-of-defun and cmake-end-of-defun that
jump to the beginning/end of the nearest function or macro.
Add the function cmake-mark-defun that marks the current function.
Bind those functions to the usual keys in cmake-mode-map.
Since commit 2642f432ef (Aux: Install editor and bash files to more
natural locations, 2020-03-30, v3.18.0-rc1~429^2) these files are
installed by default into locations that are not CMake-specific but may
be distro-specific. Add options for packagers to control these
locations.
Also rename the `CMAKE_BASH_COMP_DIR` option to follow our conventions.
Fixes: #20993
The vim, emacs, and bash support files are not internal CMake resources
and so do not belong under `CMAKE_DATA_DIR`. Move them over to proper
places under the `CMAKE_XDGDATA_DIR` as we do already for cmake-gui
desktop files and `cmake.m4`.
Fixes: #20522
Add a `JOB_POOL_PRECOMPILE_HEADER` target property to specify the pool
name, and its associated `CMAKE_JOB_POOL_PRECOMPILE_HEADER` variable.
Fixes: #20217
The `cmake--parent-mode` alias exists only for compatibility and breaks
Emacs packages and scripts that make use of `prog-mode-hook` because
Emacs does not examine whether the parent mode is an alias or not.
Remove the alias and require Emacs 24 or higher.
Emacs 24 was released in 2012 and this is already 2019, thus the loss to
drop support for versions < 24 is negligible.
a9180ccf9a Tests: add a check for the Swift compiler
d745551fb6 Help: add some initial documentation for Swift support
9a182c9e5b Auxiliary: update vim syntax highlighting
e9b0063e8e Modules: add build rules for Swift Ninja support
b6412e3e38 Ninja: add placeholders to support Swift build
7d7f31161d Ninja: add support for Swift's output-file-map.json
d688c4c19d Swift: remove unnecessary unreleased Ninja infrastructure
0723582208 Swift: Detect compiler version
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3297
In commit beb991110d (Remove now-unused code once used on IRIX,
2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support.
Also remove remnants of MIPSpro compiler support.
Adds `Fortran_COMPILER_ID` and `Fortran_COMPILER_VERSION` generator
expression support to match equivalent `C_COMPILER_ID`,
`CXX_COMPILER_ID`, `C_COMPILER_VERSION`, and `CXX_COMPILER_VERSION`
support.
This is very helpful in the case where the C/C++ compiler suite is a
different type of compiler from the platform Fortran compiler and
projects use generator expressions to assign compiler flags and
definitions. (e.g. `GNU` C/C++ and `SunPro` Fortran on Linux)
This option only has an effect if at least one of the other LOG_<step>
options is enabled. If an error occurs for a step which has logging to
file enabled, that step's output will be printed to the console. For
cases where a large amount of output is recorded, just the end of that
output may be printed to the console.
Most steps support the logging into a file but the patch command is a
notable exception. This commit adds the LOG_PATCH options that acts as
the other LOG_* options.
In some circumstances the user of ExternalProject may not desire the
split log files for stdout and stderr. In particular with a project has
many errors it can be difficult to correlate the output error with the
command that it resulted from.
This commit adds the LOG_MERGED_STDOUTERR option that when enabled
outputs into a unified <name>-<step>.log for each step. If disabled it
will default to the previous behaviour of <name>-<step>-out.log and
<name>-<step>-err.log.
