Skip to content
GitLab
Closed
Issue created by Patrik Huber@patrikhuber

FindMATLAB: Support for 2017b/2018a C++ MEX

Hi!

In R2018, Matlab and the Matlab Compiler Runtime (MCR) added a new and completely awesome C++ MEX API - now we don't need an ugly, 15+ years old C API anymore to write Matlab bindings in C++ code.

Matlab/MCR added two new libraries for this: libMatlabDataArray.lib and libMatlabEngine.lib. If I use the existing CMake FindMATLAB script, matlab_add_mex, and then in Visual Studio manually add these two libraries to the linker command-line, it seems to work fine, as far as I can tell now. Actually, libMatlabEngine.lib is not a hard-requirement - if you have very simple bindings, it seems to compile without it, but for pretty much anything you'd need libMatlabEngine.lib too.

The header that it's looking for is mex.hpp (in the same directory as mex.h).

Matlab started adding this functionality in R2017b with the MATLAB Engine API for C++ and MATLAB Data Array, and added the C++ MEX Interface in 2018a - so I think some of this stuff (all?) might work in 2017b too but I don't have it to try.

It would be really great to have this added to CMake's FindMATLAB logic.

CC @raffienficiaud :-)

By the way, one side note, I noticed that if you compile from within Matlab with mex, mex compiles a second file to an object file, namely MATLAB\R2018a\extern\version\cpp_mexapi_version.cpp (or the "c" equivalent for the old C MEX API), and then links this file, as well as my own bindings code, to produce the final output mex binary file. On the other hand, if I use CMake's matlab_add_mex, then that version files does not seem to get compiled & linked. Why is that, and can it ever be a problem?

Resources, if needed:

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information