On Windows, when FindMatlab.cmake searches the registry for installed Matlab versions, it sorts these versions alphabetically.
Since Matlab 2021a (version 9.10) came out this became a problem as now version 9.10 is placed after 9.1 instead of after a higher version less than 9.10.
The result is that FindMatlab doesn't return the highest version by default.
This fix uses the natural sort comparison which was introduced in CMake 3.18.
In commit bda5e2ac8f (FindMatlab: Only include engine and dataarray
libraries if they are found, 2020-12-11, v3.20.0-rc1~297^2~1) we fixed
the imported target to contain optional libraries only if they are
found. Do the same for `Matlab_LIBRARIES`.
An "unknown" version does not always mean an old version. Setting this
macro by mistake does not result in a compilation error, but not setting
it does. I had this error when compiling from a user that does not have
a matlab license.
Before this modification, the c_mexapi_version.c file was added to
all mex libraries. However, if the C language was not enabled
in the CMake project configuration, the c_mexapi_version.c file
was ignored, creating linking errors in Windows and macOS.
This commit ensures that in the case only the CXX languages is enabled,
the correct version is passed.
Fixes: #19382
56e89e50d3 FindMatlab: simplify several if()-constructs
51bcdeb17f Tests: simplify checks for Matlab variables being set
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3472
- These options are equivalent to `mex` command options `-R2017b` and `-R2018a`.
- `R2017b` is the default, and selects the compatability API.
- `R2018a` is the alternative, and selects the new complex-interleaved API.
- For versions of MATLAB before R2018a, these options are ignored.
- `matlab_add_mex` now works correctly with newer MATLABs.
* Determining automatically the MCR version on OSX and Windows
* Distinguishing between MCR and Matlab
* Specific tests for the MCR
* mexext on windows does not work properly: the mexext is hardcoded
* Doc updates for the MCR
Fixes: #16487
If the value of `CMAKE_HOST_SYSTEM_PROCESSOR` also happens to be set as
a variable by a project (e.g. `AMD64`), allowing `if()` to
auto-dereference is unlikely to produce a value that matches "64".
Instead let `if()` auto-dereference `CMAKE_HOST_SYSTEM_PROCESSOR`.
Fixes: #17460
Some are user facing.
Found using
codespell -q 3 --skip="./Utilities" -I .cmake-whitelist.txt`
whereby the whitelist contained:
ans
dum
helpfull
emmited
emmitted
buil
iff
isnt
nto
ot
pathes
substract
te
todays
upto
whitespaces
