Splitting code generation and building MEX into two steps
Show older comments
Question primarily intended towards MATLAB staff, But answers from the helping community are welcome
I typically use codegen command with a mex config object to generate MEX file for distribution in my org. I also notice that the MATLAB versions used by different teams/individuals in my org be different (But all in Windows platform).
I can see that that there is an option in the codegen configuration object to only generate code (genCodeOnly) or also build the (mex) object by setting false or true.
Question 1) Why can't matlab allow only code generation using the latest version (say 2024a), and build a mex file using an older version (say 2018a) - In that case, I would reasonably expect (but not guaranteed) the MEX file generated in 2018a to work in all future releases, i.e why not allow me to split it into two different steps? If this is possible - How to do it?
Question 2) Lets say I generate only code using 2024a (and not a mex file), I can see that the mex option can already handle a release (-R2018a) option. How to use such option to only build mex on a previously generated code by codegen?
9 Comments
Infinite_king
on 15 Apr 2024
Hi Sri Raman A,
1) The code generated for 'mex' configuration using the 'codegen' command will depend on the version of MATLAB. This is because the generated code utilizes MATLAB Library functions, which may vary depending on the MATLAB version. Refer to the following MATLAB documentation, https://www.mathworks.com/help/matlab/matlab_external/version-compatibility.html
There is an existing workflow of generating only code and later compiling the files to generate a mex file, usually with the help of a batch file and a makefile. However, this workflow is not useful in this case, since the generated code uses version-specific library calls and may not compile in other versions.
To generate the mex file from the generated code, simply running the batch file named "$(outputMexName)_mex.bat" is sufficient. To generate the mex file from the generated code after moving the code to another system, the "environment setup" batch file and makefile should be modified accordingly.
2) The 'mex' command is used to generate the mex file from the given 'C' or 'C++' source file. The flag (-2018a) is used to specify the release-specific API. This option won't be useful for the current problem.
Sri Raman A
on 15 Apr 2024
Infinite_king
on 15 Apr 2024
Edited: Infinite_king
on 15 Apr 2024
The use case of 'dll,' 'exe,' or 'lib' configurations is to generate code or executables that will run independently from MATLAB. However, the primary goal of 'mex' is to utilize MATLAB while decreasing execution time. Hence, the generated code for the 'mex' workflow still uses MATLAB Library calls, whereas other workflows will not. One advantage of using MATLAB compared to independent executions is that the 'mex' workflow supports GUI functions like plotting, whereas other workflows do not support them.
Sri Raman A
on 15 Apr 2024
Edited: Sri Raman A
on 15 Apr 2024
Infinite_king
on 15 Apr 2024
Sri Raman A
on 15 Apr 2024
Infinite_king
on 16 Apr 2024
Edited: Infinite_king
on 16 Apr 2024
The simplest workaround that I can think of is to share the source code instead of the mex file and ask them to compile it to mex in their version of MATLAB or supply a simple script to compile the function into mex. Instead of a plain script file, a P-code file can be shared to make the source file unreadable.
Sri Raman A
on 16 Apr 2024
Infinite_king
on 16 Apr 2024
For the workaround that i provided, MATLAB coder is needed to compile the P-code to mex.
Contact Technical support, you may get better workaround :- https://www.mathworks.com/support/contact_us.html
Answers (0)
Categories
Find more on MATLAB Coder in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!