Fix compiling MEX function on Windows

[diegoferigo]

• Updated FindMatlab.cmake with the latest upstream version
• Changed external symbol to const. This change has to be tested on Windows.

Fixes #44 and robotology/robotology-superbuild#226.

[diegoferigo]

Then, on @RAR1989 setup, adding to PATH the <plugin-install-prefix>/blockfactory/bin and <plugin-install-prefix>/blockfactory/lib was necessary.

I am not really sure about the lib folder because it should be handled by blockfactory after setting the BLOCKFACTORY_PLUGIN_PATH. The missing bin folder, though, was the source of the errors described in robotology/robotology-superbuild#226. @RAR1989 can you please try to remove the lib entry and check if everything works correctly?

[traversaro]

This error is now blocking the Windows CI for robotology-superbuild, see https://github.com/robotology/robotology-superbuild/pull/296/checks?check_run_id=303624209 . Unfortunately I don't have Windows with Matlab, so I can't test directly this PR, @DanielePucci can we get someone with Windows + Matlab from the lab to test this fix so that we can merge the PR? Thanks!

[traversaro]

Changed external symbol to const. This change has to be tested on Windows.

As discussed in robotology/robotology-superbuild#226 (comment), unfortunately CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS is not able to export automatically static and global data variables, so those need to be manually exported (see robotology/how-to-export-cpp-library#41), so those need to be manually exported, for example using generate_export_header. An alternative is to move the variable in the header and declare it as inline.

[DanielePucci]

@traversaro there should be Matlab+Windows on the "Monster" (btw, we should find a mapping between acronyms and official IIT names). So @diegoferigo was telling me that he could test the PR next week on it

[traversaro]

Great!

[traversaro]

With Matlab 2019b, this PR is now failing with the following error:

LINK : error LNK2001: unresolved external symbol mexfilerequiredapiversion [C:\src\robotology-superbuild\build\robotology\BlockFactory\sources\Simulink\Simulink.vcxproj]
C:/src/robotology-superbuild/build/robotology/BlockFactory/lib/Debug/BlockFactoryd.lib : fatal error LNK1120: 1 unresolved externals [C:\src\robotology-superbuild\build\robotology\BlockFactory\sources\Simulink\Simulink.vcxproj]

Indeed, this make sense as mexfilerequiredapiversion is a symbol that is explictly requested to be part of the Mex funtion in the CMake code, and we do not define in our mex function.

[traversaro]

With Matlab 2019b, this PR is now failing with the following error:

LINK : error LNK2001: unresolved external symbol mexfilerequiredapiversion [C:\src\robotology-superbuild\build\robotology\BlockFactory\sources\Simulink\Simulink.vcxproj]
C:/src/robotology-superbuild/build/robotology/BlockFactory/lib/Debug/BlockFactoryd.lib : fatal error LNK1120: 1 unresolved externals [C:\src\robotology-superbuild\build\robotology\BlockFactory\sources\Simulink\Simulink.vcxproj]

Indeed, this make sense as mexfilerequiredapiversion is a symbol that is explictly requested to be part of the Mex funtion in the CMake code, and we do not define in our mex function.

This is not true. The function should be defined by

blockfactory/cmake/FindMatlab.cmake

Line 1015 in 724c934

${MEX_VERSION_FILE}

, but for some reason is not defined correctly, perhaps it is incorrectly compiled with the C++ mangling.

[traversaro]

Ok, that was fun to debug. : )
First of all I wanted to check why the symbol mexfilerequiredapiversion was not there, so I went where the object files for each compilation unit were stored, i.e. in <build>\sources\Simulink\Simulink.dir\Release. There I had only three .obj files:

• SimulinkBlockInformation.obj, output of the compilation of https://github.com/robotology/blockfactory/blob/v0.8/sources/Simulink/src/SimulinkBlockInformation.cpp
• SimulinkBlockInformationImpl.obj, output of the compilation of https://github.com/robotology/blockfactory/blob/v0.8/sources/Simulink/src/SimulinkBlockInformationImpl.cpp
• BlockFactory.obj, output of the compilation of https://github.com/robotology/blockfactory/blob/v0.8/sources/Simulink/src/BlockFactory.cpp

There was no c_mexapi_version.obj, that was supposed to be the output of the compilation of the Matlab-provided c_mexapi_version.c file (see

blockfactory/cmake/FindMatlab.cmake

Line 980 in 724c934

set(MEX_VERSION_FILE "${Matlab_ROOT_DIR}/extern/version/c_mexapi_version.c")

) that is the one the Matlab provided file that defines mexfilerequiredapiversion.

For some reason, the c_mexapi_version.c file was ignored and not compiled even if it was added to the BlockFactory Mex library in

blockfactory/cmake/FindMatlab.cmake

Line 1015 in 724c934

${MEX_VERSION_FILE}

. What was the reason of that? Simply that the BlockFactory CMake project was configured in https://github.com/robotology/blockfactory/blob/v0.8/CMakeLists.txt#L6 as just be a project for compiling C++, so it silently ignores any C file. Adding C to the LANGUAGES option of the project CMake function call solved the problem.

This is not the first problem that I have with CMake projects that only decleare CXX as a project language, as a lot of Find***.cmake scripts actually try to compile C files for checking some characteristics of the library of the build environment, so in general I think it is wiser to always configure CMake projects with C and CXX as enabled languages, see robotology/how-to-export-cpp-library#25 and https://github.com/robotology/how-to-export-cpp-library/blob/307f7bd78789cb68aa58c7804a3549ec23679483/CMakeLists.txt#L17 for related info.

[traversaro]

Related CMake upstream issues and MR:

• https://gitlab.kitware.com/cmake/cmake/issues/19382#note_679312
• https://gitlab.kitware.com/cmake/cmake/merge_requests/4206

[traversaro]

I tested the PR with the modified FindMatlab file available in robotology-dependencies/qpOASES#13 , and indeed now the compilation is working fine. Adding the inline specifier as discussed in #45 (comment) works fine as well, but actually do to do we will need to require C++17, as inline variables are only supported since C++17, see https://en.cppreference.com/w/cpp/language/inline .

[traversaro]

As discussed in robotology-dependencies/qpOASES#13 , I suggest to change this PR to use the FindMatlab that will be shipped with CMake 3.16.3, see https://gitlab.kitware.com/cmake/cmake/blob/e6c5bed2aa4ec729dd9d91c056c0147a1f5cd16e/Modules/FindMatlab.cmake .

[traversaro]

CMake 3.16.3 has been released with the fixes of FindMatlab.cmake useful to fix all the Windows linking problems, see https://discourse.cmake.org/t/cmake-3-16-3-available-for-download/530 .

[diegoferigo]

Replaced by #54