The `find_package_handle_standard_args(FOUND_VAR)` is deprecated as of
CMake 3.3 and both the `<PackageName>_FOUND` and the upper-cased
`<PACKAGE_NAME>_FOUND` are set with or without using this option.
Additionally, find modules and docs are also synced with this to make it
clearer.
This will now preserve empty values in the TEST_LAUNCHER and
CROSSCOMPILING_EMULATOR target properties for tests added by:
- The add_test() command.
- The ExternalData_Add_Test() command from the ExternalData module.
- The gtest_add_tests() or gtest_discover_tests() commands from the
GoogleTest module.
For the gtest_add_tests() and gtest_discover_tests() commands,
empty elements in the values passed after the EXTRA_ARGS keyword
are also now preserved.
Policy CMP0178 is added to provide backward compatibility with the
old behavior where empty values were silently discarded from the
above cases.
Fixes: #26337
9ceca05e6b FindMatlab: Search mex and mx libraries for MCR
67e3c6b6eb FindMatlab: Cache whether MATLAB root contains MCR or MATLAB
b426ce1d04 FindMatlab: Add support for MCR distributions without mex.h
cd4782bac3 FindMatlab: Only consider versioned MCR subdirectory if it exists
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9831
Revise commit 657064b6d4 (FindMatlab: Refactor: Eliminate
_matlab_64Build, 2024-01-24, v3.30.0-rc1~594^2~5) to more faithfully
reproduce the original behavior.
Revise commit 91c672e5ae (FindMatlab: Use find_package(Threads) instead
of checking -pthread, 2024-02-02, v3.30.0-rc1~594^2~1) to restore the
old behavior of looking for threads only with C or CXX enabled.
Fixes: #26121
CMake 3.24 added REGISTRY_VIEW as find_package argument. Since
FindMatlab.cmake looks up the registry, we might as well support it.
While some logic existed to select the correct registry view when
searching for the installed versions, that logic was not applied when
getting the matlab root directories, which might have led to weird
situations in which both the 32-bit and 64-bit version of the same
Matlab release were installed simultaneously.
The changes made in this commit try not to break existing and documented
behavior from exposed functions. The exposed functions which interact
with the registry get an optional `REGISTRY_VIEW` argument.
If no REGISTRY_VIEW is passed to find_package, FindMatlab uses the
`TARGET` view to mimic the previous behavior.
`matlab_extract_all_installed_versions_from_registry` searched for
32-bit installations on 32-bit Windows even if win64 was set to 'TRUE'.
Now, no installation will be found if win64 is set to 'TRUE' on 32-bit
Windows, which is also the documented behavior.
c273fc4ffb FindMatlab: Handle version range
3665fe26ba FindMatlab: Refactor version selection using find_package_check_version
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9221
Partially revert commit dc9d9589e4 (FindMatlab:WIN32: return full Matlab
version when found via registry, 2023-09-14, v3.28.0-rc1~82^2~2). It
changed `matlab_extract_all_installed_versions_from_registry` behavior
to query `VersionInfo.xml` for version information. However, the
function documentation states that it only uses the registry. It's also
not needed since commit c608adc236 (FindMatlab: Fix major.minor version
lookups in Windows Registry, 2024-01-11, v3.28.2~13^2~1), which added
the same lookup to `matlab_get_all_valid_matlab_roots_from_registry`.
This adds -w to to the version source file's compile options.
Currently, this is done for Clang and compilers officially supported by
Matlab.
Fixes: #24851
b8665d44ba FindMatlab: Fix error message from function
44d2cf3ed4 FindMatlab: Document all registry paths for version lookup
363a7d4693 FindMatlab: matlab_get_release_name_from_version is a function now
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !9175
6f7d87b40d FindMatlab: use NAMES for find_*
9e97893147 FindMatlab: set MATLAB_ARCH per process call
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9161
