In commit 8d7e80cf3d (find_* commands: add control over Windows registry
views, 2022-04-16, v3.24.0-rc1~201^2) this indentation was used for the
other find commands but was left out for `find_package`.
The documentation of the find-commands was pointing to the
cmake variables CMAKE_PREFIX_PATH, CMAKE_INCLUDE_PATH etc.
also in the section for environment variables. Now they point
to the documentation for the respective environment variables.
Extend commit eb35d8884b (find_package: Use PackageName_ROOT variables
as search prefixes, 2018-03-15, v3.12.0-rc1~349^2) to also check
upper-case `<PACKAGENAME>_ROOT` variables. Add policy `CMP0144` to
enable the behavior in a compatible way.
Fixes: #24403
Add a `versionadded` mark for the search path added by commit e55c154c5b
(cmFindPackageCommand: Add one more search path, 2022-06-27,
v3.25.0-rc1~339^2~1).
Fixes: #24067
a6abdf6c8f Help: Consistent options declaration -- short first, then long
f4563f05db Help: Value for `--graphviz=` option actually is mandatory
04843d743e Help: Replace a bunch of more ``--option`` to `:option:` role
09446266ee Help: Replace mentions of ``-D`` option with :option:`-D` role
b57f27b087 Help: Replace mentions of ``-T`` and ``-A`` options with role
d25b232dee Help: Replace mentions of ``-G`` option with :option:`-G` role
63940e1cab Help: Replace mentions of ``-C`` option with :option:`-C` role
183a49cbfe Help: Replace mentions of ``-S`` option with :option:`-S` role
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7544
The `PREFIX/(Foo|foo|FOO).*/(cmake|CMake)/(Foo|foo|FOO).*/` search
path is the similar to the one already exists
`PREFIX/(Foo|foo|FOO).*/(lib/ARCH|lib*|share)/cmake/(Foo|foo|FOO).*/`.
92e93f5c9e Help: Overhaul and expand the Using Dependencies Guide
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Alex <leha-bot@yandex.ru>
Merge-request: !7332
The guide previously only focused on the find_package() command,
with a bias towards libraries. FetchContent was not mentioned at all.
Reorganise and update the existing content. Add new sections to cover
providing dependencies with FetchContent and dependency providers.
Improve discoverability of the guide by mentioning it at the beginning
of the find_package(), FetchContent and dependency provider docs.
In commit 8d7e80cf3d (find_* commands: add control over Windows registry
views, 2022-04-16) we added documentation that is repeated by multiple
find commands. Move it to a dedicated manual section to avoid duplication.
Allow FetchContent_MakeAvailable() to try a call to
find_package() first, or redirect a find_package() call to
FetchContent_MakeAvailable(). The user can set variables
to control which of these are allowed or tried by default.
Fixes: #21687
Not all the behaviors of CMake variables for ignoring search
locations by find_...() commands were fully documented.
Add the missing effects, clarify the wording and restructure the
way the details are assembled to reduce duplication.
Also improve the cross-referencing to ensure all the related
variables are more discoverable.
Issue: #20878
Allow find package to promote scope of imported targets by specifying
an argument to `find_package` or by specifying a CMake variable.
* Add support for CMAKE_GLOBAL_IMPORT_SCOPE variable
* Add support for GLOBAL argument to find_package
Additionally add testing for above features.
The explanation of the basic and full signatures was interwoven tightly
with that of the Module and Config search modes. Config mode is
supported by both signatures, which made the structure of the
command documentation a bit confusing.
Add a section at the start which unambiguously describes the two
modes, including the fallback functionality between them. Move the
text about this out of the basic signature section, leaving just a
description of the basic syntax with a note that it is supported by both
search modes. This makes the basic signature section more focused.
Drop the Module and Config mode parts of the titles for the basic and
full signature sections. Those are now more precisely covered by the
new opening section, so the Basic Signature and Full Signature sections
are now clearer in what they cover.
Swap the order of the Search Procedure and Version Selection sections
to improve the logical flow. Also add "Config Mode" to their titles to
make it clearer what they apply to. Add a note at the start of both
sections to highlight their relationship to the basic and full signatures.
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.
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
Extend the change from commit 1d00ba9ccf (Find: find_package prefers
variable CMAKE_FIND_USE_REGISTRY, 2018-11-13, v3.16.0-rc1~461^2~1)
to cover the system package registry too.
Fixes: #19890
CMake's find control flags should all have a consistent name.
To make this happen we are introducing `CMAKE_FIND_USE_REGISTRY`
and deprecating `CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY`.
