This marks all `<PACKAGENAME>_FOUND` result variables as deprecated
where possible (for `<PackageName>` find modules) to make it clearer
which variable to use.
In CMake 3.3, the FindPackageHandleStandardArgs module was refactored to
set both `<PackageName>_FOUND` and uppercase `<PACKAGENAME>_FOUND`
result variables to the same values. Before that, the FOUND_VAR argument
could be used to set the result variable.
* FindMatlab: Uppercased MATLAB_FOUND is not mentioned as it was never
documented.
* Documentation for FindPythonInterp and FindPythonLibs modules synced
accordingly to their deprecation (3.12 instead of 4.2).
* OPENGL_FOUND: deprecation version synced with other find modules.
* DevIL_FOUND was introduced in CMake 3.8. The uppercased variant not
mentioned as it was previously never documented.
Fixes: #27242
Since commit d74210a8bd (CMP0017: Remove support for OLD behavior,
2024-11-17) we can rely on CMP0017's NEW behavior unconditionally.
Calling `include(FindPackageHandleStandardArgs)` in a builtin module
will always get the builtin `FindPackageHandleStandardArgs`.
Documentation was added by commit 905d5667e8 (FindRuby: Add support for
RVM installations, 2020-03-23, v3.18.0-rc1~497^2), but this feature was
never implemented.
Closes: #21528
The possible executable names list always starts with a plain "ruby"
binary, which is scanned for first. If that does exist (which satisfies
find_program), but doesn't match the requested version, the executable
will be dismissed by _RUBY_VALIDATE_INTERPRETER (which is sane), but
searching also stops.
Fix that by keeping the search going, removing items from the list as we
go, until find_program returns a path that _RUBY_VALIDATE_INTERPRETER is
happy with or the list is empty.
Since commit e672db628b (FindRuby: Rename variables to match case of
module name, 2020-03-11, v3.18.0-rc1~546^2), the result variables named
with the old `RUBY_` prefix are provided by compatibility code that maps
from the new `Ruby_` prefix variables. This variable was accidentally
left out.
Fixes: #21369
Since commit e672db628b (FindRuby: Rename variables to match case of
module name, 2020-03-11, v3.18.0-rc1~546^2), the upper-case-prefixed
variable names are for compatibility only but still exist. Put them
back in the documentation.
Issue: #21064
Since commit e672db628b (FindRuby: Rename variables to match case of
module name, 2020-03-11, v3.18.0-rc1~546^2), the result variables named
with the old `RUBY_` prefix are provided by compatibility code that maps
from the new `Ruby_` prefix variables. There is no `Ruby_INCLUDE_PATH`
variable, so do not try to map it to `RUBY_INCLUDE_PATH`. The latter is
provided by dedicated compatibility code left from before that
transition.
Fixes: #21064
Use the `MSVC_TOOLSET_VERSION` variable computed by CMake to get the
matching Ruby library name component.
Inspired-by: Julien Marrec <julien.marrec@gmail.com>
In commit e672db628b (FindRuby: Rename variables to match case of module
name, 2020-03-11) compatibility was provided for result variables but
not for the cache entries that scripts might set.
Use recommended case for variable names, i.e. matching name of the
module as passed to `find_package`.
For backwards compatibility, the upper case versions of both input and
output variables are used and defined when appropriate. Skip this for
the _FOUND variable because FPHSA already does it.
This follows the approach from commit a7b09e7f43 (FindProtobuf: Rename
variables to match case of module name, 2016-03-01, v3.6.0-rc1~273^2).
Issue: #20370
