2c71d051fa Makefiles Generators: use compiler for dependencies generation
afd0f6785d Refactoring: Abstract Makefile line continuation format
b6068ce407 Refactoring: enhance include file filtering
3401403f69 Refactoring: Introduce place-holder for dependency target.
a97c41bf8b Refactoring: Makefiles Generators: Add support for various depends scanners
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Brad King <brad.king@kitware.com>
Merge-request: !5528
573d51201a GENERATED prop: Set CMP0118 to NEW for some (unrelated) tests
6624b65b3f GENERATED prop: Add implementation for policy CMP0118 being set to NEW
b14fe704f8 GENERATED prop: Simplify determining the language of a source file
ca4ce458a3 GENERATED prop: Check CMP0118 policy and warn in certain situations
0eb30f175e GENERATED prop: Introducing policy CMP0118 and its documentation
78c8d95605 GENERATED prop: Add some tests before introducing changes with CMP0118
e01527619f Simplify code by calling a function directly instead of duplicating it
75cb8615e9 Fix typo in function name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5308
NVCC's default architecture may be newer than the one supported by the
machine's GPU.
In such cases it's useful to have an environment variable for initializing
CMAKE_CUDA_ARCHITECTURES to avoid specifying it for every invocation.
In 5651901c54 (Xcode: add support for embedding frameworks, 2020-10-24)
we neglected to add a release note for the new target properties
that were added.
Each source compilation generates a dependencies file. These dependencies
files are consolidated in one file per target. This consolidation is done
as part of command 'cmake -E cmake_depends` launched before evaluation of
makefile dependency graph.
The consolidation uses the same approach as `CMake` dependencies management.
Fixes: #21321
This commit also prepares for embedding things other than
frameworks. In the future, we may want to embed resources and
other types supported by Xcode, so the target properties have
been documented in a way that clearly signals the future intent.
Add CPACK_IFW_PACKAGE_WIZARD_SHOW_PAGE_LIST variable to
control visibility of the widget listing installer pages on the left side
of the wizard. This feature available only since QtIFW 4.0.
Initialize it with placeholder content. This document will serve to
contain documentation for experimental features that are under
development and not yet included in official documentation.
version.txt is gone from CUDA 11.1 installations, but the rest is the same.
Instead of looking for version.txt look for <CUDA path>/nvvm/libdevice, which
is the main thing that Clang requires (though it also checks for the existence
of bin and include).
Fixes#21353.
In commit cb28d9af1f (UseJava: Move helper scripts to subdirectory,
2020-11-12) we removed modules that were not meant to be documented
publicly. In order to keep links from older versions on `cmake.org` to
the "latest" documentation working for those modules, add placeholder
documents describing the change.
Revert commit 74b1c9fc8e (Explicitly specify language flag when source
LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup
tables from its two immediate ancestors. The purpose of that change was
to convert an explicit `LANGUAGE` source file property into an explicit
language specification compiler flag like `-x c`. This seems reasonable
since the property is documented as meaning "indicate what programming
language the source file is". It is also needed to help compilers deal
with non-standard source file extensions they don't recognize.
However, some projects have been setting `LANGUAGE C` on `.S` assembler
source files to mean "use the C compiler". Passing `-x c` for them
breaks the build because the `.S` sources are not written in C. These
projects should be updated to use `enable_language(ASM)`, for which
CMake often chooses the C compiler as the assembler when using
toolchains that support it (which would have to be the case for projects
using the approach).
Revert the change for now to preserve the old behavior for such projects.
We can re-introduce it with a policy in a future version of CMake.
Fixes: #21469
Issue: #14516, #20716
c00a6d3967 MSVC: Do not add /GR to CMAKE_CXX_FLAGS by default
6114c8e994 MSVC: Factor out initialization of /GR flag
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5508
The `/GR` flag has been on by default since MSVC cl 14.0 from VS 2005.
Remove it from the default flags to make it easier for projects to pass
`/GR-` themselves to turn it off.
Projects may be using string processing to replace `/GR` with another
flag, so we cannot simply drop it. Add a policy to drop it in a
compatible way.
Fixes: #21428
More `.. versionadded` could be added later when the features,
variables and properties relevant to each generator are properly
documented.
Issue: #19715
`.. versionchanged` directive might be more appropriate when
documentation refers to previous CMake version, old behavior
or a policy, and there's no new parameter or a variable involved.
Issue: #19715
Many environment variables were documented late and got
assigned wrong versions by the script.
(The whole Help/envvar section was only added in 3.10).
Issue: #19715
There was an ambiguity in the wording with the meaning of "or" typically
meaning exclusive-or in prose. Instead, ensure that the easiest parsing
is clear that the directory part is always removed.
This change ony concerns directives that appear in the document body.
The guidelines for inserting version directives:
* Baseline version is CMake 3.0, i.e. directives start at 3.1.
* Always use `.. versionadded::` directive, avoid ad-hoc version
references. Exception: policy pages.
* For new command signatures, put `versionadded` on a separate line
after the signature.
* For a group of new signatures in a new document section,
a single version note at the beginning of the section is sufficient.
* For new options, put `versionadded` on a separate line before
option description.
* If all the option descriptions in the list are short one-liners,
it's fine to put `versionadded` on the same line as the description.
* If multiple option descriptions in close proximity would have
the same ..versionadded directive, consider adding a single
directive after the list, mentioning all added options.
* For compact value lists and sub-option lists, put a single
`versionadded` directive after the list mentioning all additions.
* When a change is described in a single paragraph, put
`versionadded` into that paragraph.
* When only part of the paragraph has changed, separate the changed
part if it doesn't break the flow. Otherwise, write a follow-up
clarification paragraph and apply version directive to that.
* When multiple version directives are close by, order earlier
additions before later additions.
* Indent related lists and code blocks to include them in the scope
of `versionadded` directive.
Issue: #19715
Brad King