Windows: The installed versions of Matlab/MCR are retrieved from theWindows registry. The REGISTRY_VIEW argument may optionally be specifiedto manually control whether 32bit or 64bit versions shall be searched for.
macOS: The installed versions of Matlab/MCR are given by the MATLABdefault installation paths in /Application. If no such application isfound, it falls back to the one that might be accessible from the PATH.
Additional information is provided when MATLAB_FIND_DEBUG is set.When a Matlab/MCR installation is found automatically and the MATLAB_VERSIONis not given, the version is queried from Matlab directly (on Windows thismay pop up a Matlab window) or from the MCR installation.
The mapping of the release names and the version of Matlab is performed bydefining pairs (name, version). The variableMATLAB_ADDITIONAL_VERSIONS may be provided before the call tothe find_package() in order to handle additional versions.
returns all the possible Matlab or MCR paths, according to a previouslygiven list. Only the existing/accessible paths are kept. This is mainlyuseful for the searching all possible Matlab installation.
By default, every symbols inside a MEXfile defined with the command matlab_add_mex() have hiddenvisibility, except for the entry point. This is the default behavior ofthe MEX compiler, which lowers the risk of symbol collision between thelibraries shipped with Matlab, and the libraries to which the MEX file islinking to. This is also the default on Windows platforms.
However, this is not sufficient in certain case, where for instance yourMEX file is linking against libraries that are already loaded by Matlab,even if those libraries have different SONAMES.A possible solution is to hide the symbols of the libraries to which theMEX target is linking to. This can be achieved in GNU GCC compilers withthe linker option -Wl,--exclude-libs,ALL.
in case your MEX file is using the GPU andin order to be able to run unit tests on this MEX file, the GPU resourcesshould be properly released by Matlab. A possible solution is to makeMatlab aware of the use of the GPU resources in the session, which can beperformed by a command such as D = gpuDevice() at the beginning ofthe test script (or via a fixture).
The root folder of the Matlab installation. If set before the call tofind_package(), the module will look for the components in thatpath. If not set, then an automatic search of Matlabwill be performed. If set, it should point to a valid version of Matlab.
The returned list contains all versions underHKLM\SOFTWARE\Mathworks\MATLAB,HKLM\SOFTWARE\Mathworks\MATLAB Runtime andHKLM\SOFTWARE\Mathworks\MATLAB Compiler Runtime or an empty list incase an error occurred (or nothing found).
Populates the Matlab root with valid versions of Matlab orMatlab Runtime (MCR).The returned matlab_roots is organized in triplets(type,version_number,matlab_root_path), where typeindicates either MATLAB or MCR.
This function runs Matlab program specified on arguments and extracts itsversion. If the path provided for the Matlab installation points to an MCRinstallation, the version is extracted from the installed files.
The function expects one Matlab test script file to be given.In the case NO_UNITTEST_FRAMEWORK is given, the unittest script fileshould contain the script to be run, plus an exit command with the exitvalue. This exit value will be passed to the ctest framework (0 success,non 0 failure). Additional arguments accepted by add_test() can bepassed through TEST_ARGS (eg. CONFIGURATION ...).
This will be the working directory for the test. If specified it willalso be the output directory used for the log file of the test run.If not specified the temporary directory $CMAKE_BINARY_DIR/Matlab willbe used as the working directory and the log location.
Adds a Matlab MEX target.This commands compiles the given sources with the current tool-chain inorder to produce a MEX file. The final name of the produced output may bespecified, as well as additional link libraries, and a documentation entryfor the MEX file. Remaining arguments of the call are passed to theadd_library() or add_executable() command.
if given, the file file.txt will be considered asbeing the documentation file for the MEX file. This file is copied intothe same folder without any processing, with the same name as the finalmex file, and with extension .m. In that case, typing help in Matlab prints the documentation contained in this file.
May be given to specify the version of the C APIto use: R2017b specifies the traditional (separate complex) C API,and corresponds to the -R2017b flag for the mex command. R2018aspecifies the new interleaved complex C API, and corresponds to the-R2018a flag for the mex command. Ignored if MATLAB version priorto R2018a. Defaults to R2017b.
I am trying to run the brainstorm binary version using MATLAB Runtime 2022b on a Windows 10 machine.
When I try to execute it using the brainstorm3.bat file, I get the following output in the command line:
I am trying to follow troubleshooting instructions at two of your links, which I have pasted below. I understand that the solution is to edit the path for @SET MATLABROOT, in the brainstorm3.bat file.
However, I don't know which @SET MATLABROOT line to edit + what path to paste in it. Would you be able to clarify this?
The first part of of the brainstorm3.bat tries to get the MATLABROOT folder from standard installation paths. I added here two more tests for trying to find the Matlab Runtime installation paths (VER_NAME=R2022b):
This illustrates the change: previously, the registry entry indicated only the path up to "MATLAB Runtime", so my batch script was adding the missing version folder (e.g. "v98").
Now, the installer registers the path including the version name (R2022b). This cause the script to generate the erroneous path you reported in your first post: C:\Program Files\MATLAB\MATLAB Runtime\R2022b\v913
Changes in Matlab are always annoying because it makes me work extra. But this one is actually fixing a "bug" of the previous installers.
This error is different : the path was not found in the registry, but it didn't report it wasn't found. I don't understand this...
Can you please try the following: save the script below as a file "getpath.bat", then double-click on it to execute it, and finally copy-paste here the full output. If the window closes too fast: open a CMD terminal, CD to the folder where the .bat file is saved, and execute it from the command line.
test.zip (394 Bytes)
@Francois, I re-downloaded/reinstalled the Brainstorm bin package as you suggested above, and now it is working. Thanks to you and @John_Mosher for working through this.
Anyhow, here is the output you requested from executing test.bat:
One undocumented tip for people who are not afraid of changing things in the MATLAB installation directories is to create *.phl files for your MATLAB path additions. When you install a new version of MATLAB copy these phl files to $matlabroot$/toolbox/local/path. Then issue the MATLAB command restoredefaultpath followed by savepath and your additions will be included in the path. There is phl file for every toolbox you have installed to use as examples.
It can save lots of future work to copy+paste some code from matlabrc.m, hgrc.m, pathdef.m, classpath.txt and others, learn about the ressources used there, and remix all this to create your own checkinstall.m, init.m, startuser.m or whatever you may call it. Of course, one can also edit any toolbox/local/*.* file directly, at least if it does not make one mad to fix a dozen of core Matlab files manually twice a year, always taking care that nothing important gets lost. Hence, I would always try to fix setup issues by user/project specific path automation scripts which are executed only on demand.
Neverthesess, I always found it quite conclusive to load the matlabrc.m and alike functions into an editor and compare them with older versions. Changes in these functions may reveal more about new features than one would find in the official Matlab release notes.
I hope I made clear that I do not citicize but rather appreciate anybody who thoroughly investigates and understands post-installation issues, specifically those who know where fixes are mandatory, optional, or even dangerous. However, take care!
There is an example Simulink model provided in the Examples repository called "Speed Controller". Recommend you use the model provided with Modeler 8.3 M020 (also called 8.3b). You will need Visual Studio and obviously Simulink installed to run. View the Readme inside the model for more information and refer to the Help.
Unfortunately in our recent testing we discovered some changes introduced into Simulink 2016b and 2017a that stop our integration working correctly. So we recommend using 2016a if possible for now. Sincere apoloiges we haven't realised this and informed you earlier. We will be looking at fixing these isses and supporting the newer versions of Simulink in a future release.
But there is something left: I do have Matlab/Simulink 2015b available as well (parallel install) and exported the model to be saved for that version. Unfortunately that alone does not help, as I did not find a way to tell the Simulink-Synchonizer which version of Matlab to use when he starts the tool. He apparently takes the Windows default (Matlab 2016b), which I do not want to move to the old version (to avoid messing up with my other activities). Simply changing the standard applications allocated in Windows to the file name extensions .m, .slx, .sltx, .sldd, .mdl to the installation of the old Matlab 2015b did not help, anyway.
Is there a way to tell the synchronizer the path to the Matlab-Version to use? Maybe through a tweek of the vbs-files that the simulink profile invokes (to avoid the need of an update of "MathematicalHelper.dll" (which contains the Starter/Wrapper-Code of the Synchronizer, if I get it right), or the MathematicalModelSynchronizer.exe itself?
4a15465005