72814e46da Utilities/Sphinx: Make HTML links in parsed-literal blocks more obvious
08b4ea639c Help: Organize file command docs into sections
51c0e1407c Help: Add Synopsis section to install, list, and string docs
0acd705119 Help: Improve list command signature group name for read operations
d5b2745b34 Help: Re-order file command docs
7d918b3cee cmRST: Parse inline links and inline literals
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2039
Evaluate to false on `$<COMPILE_LANGUAGE:Lang>` if language `Lang`
is not loaded. This is helpful in exported targets consumed in other
projects that may not enable all the same languages.
Fixes: #17952
7e8046e20b Help: add release notes for NAMELINK_COMPONENT
c02eeb0853 Help: clarify "undefined behavior" in install(EXPORT) command
edcb545a24 install: add test for new NAMELINK_COMPONENT parameter
0212d7c762 install: add NAMELINK_COMPONENT argument
cbb609072f Help: clean up install(TARGETS) documentation
b81280ba1f Help: add list of command signatures to top of INSTALL page
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex Turbov <i.zaufi@gmail.com>
Merge-request: !1982
* Introduce `CMAKE_PROJECT_VERSION` and the corresponsing components:
`CMAKE_PROJECT_VERSION_MAJOR`, `CMAKE_PROJECT_VERSION_MINOR`,
`CMAKE_PROJECT_VERSION_PATCH` and `CMAKE_PROJECT_VERSION_TWEAK`.
* `CPack` module use `CMAKE_PROJECT_VERSION_MAJOR`,
`CMAKE_PROJECT_VERSION_MINOR` and `CMAKE_PROJECT_VERSION_PATCH`
to initialize corresponsing CPack variables.
The two-argument forms of `AddDefineFlag` and `RemoveDefineFlag`
need no access to `cmMakefile` class members. They are used only
within the implementation file.
When calling
source_group(TREE <root> PREFIX "" FILES ...)
the files located at the root directory were not assigned
to the correct source group: they were put in a default
group (e.g. "Source Files" in Visual Studio).
Fixes: #17608
In some environments the linker produces warnings like
warning: directory not found for option
warning: object file compiled with -mlong-branch ...
These do not affect the availability of C++ features we're checking,
so filter them out.
Fixes: #17850, #17947
This is primarily a cleanup of the cpack(1) page. The cpack.cxx file
and CPack module were also updated to make the docs relating to
the generator specification and option names consistent in all
three places.
de549083e3 cmVisualStudio10TargetGenerator: warn if /clr flag is set manually
59ec7d50bd cmVisualStudio10TargetGenerator: fix for backward compatibility
663f5120f4 cmGlobalVisualStudioGenerator: remove TargetCanBeReferenced()
359544a907 add tests for using target_link_libraries() with imported managed targets
43571073e0 cmVisualStudio10TargetGenerator: store managed reference information in maps
16fec7e2fc cmVisualStudio10TargetGenerator: make some methods config aware
f3c6828876 cmVisualStudio10TargetGenerator: /clr compatible flags for managed tgt
f9042d807d remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1805
Since its beginning the Ninja generator has handled `GENERATED` source
files that have no custom command producing them by writing a dummy
custom command for them that depends on the target ordering phony edge.
Make the custom command's dependency order-only since the phony edge
also has only order-only dependencies. The dummy custom command
should never be considered "dirty" by `ninja`.
Fixes: #17942
Since commit v3.9.0-rc1~230^2~2 (ninja: break unnecessary target
dependencies, 2017-04-17) we unconditionally generate a phony edge for
target ordering. It is needed in case a later target depends on it.
However, if the phony edge has no inputs then `ninja -d explain` prints:
ninja explain: output ... of phony edge with no inputs doesn't exist
Furthermore the phony edge's output is considered dirty and can cause
dependents to be incorrectly considered dirty. Avoid this by always
generating at least one input to the target ordering phony edges.
If we have no real dependencies just use a path that always exists.
Fixes: #17942
Internally we mark `file(GENERATE)` outputs as `GENERATED` in order
to tell custom command dependency tracing logic not to expect the
files to exist on disk yet. This is because we do not generate the
files until after that tracing is done.
The Ninja generator also interprets the `GENERATED` property to mean
that it is expected that some build rule will generate the file if
another build rule depends on it. If the generator does not know of a
custom command that generates the file then it adds an empty one so that
the `ninja` build tool does not complain about a dependency on a file
that does not exist and has no rule to generate it. However, this step
is not necessary for `file(GENERATE)` outputs because there is no build
rule to generate them and they will exist before `ninja` runs.
Add an additional `__CMAKE_GENERATED_BY_CMAKE` property internally to
tell the Ninja generator that a `GENERATED` file will exist before the
build starts and is not expected to have a build rule producing it.
Fixes: #17942