Add recipe for libmatio-cpp

[traversaro]

Add recipe for matio-cpp.

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/matio-cpp) and found it was in an excellent condition.

[traversaro]

Windows build fails with:

[32/35] Building CXX object test\CMakeFiles\ExogenousConversionsUnitTests.dir\ExogenousConversionsUnitTest.cpp.obj
FAILED: test/CMakeFiles/ExogenousConversionsUnitTests.dir/ExogenousConversionsUnitTest.cpp.obj 
C:\PROGRA~2\MICROS~1\2019\ENTERP~1\VC\Tools\MSVC\1416~1.270\bin\HostX64\x64\cl.exe  /nologo /TP -DCATCH_CONFIG_DISABLE_MATCHERS -DCATCH_CONFIG_FAST_COMPILE -I%SRC_DIR%\build\test -I%SRC_DIR%\include -I%SRC_DIR%\build\Autogenerated -I%PREFIX%\Library\include -I%PREFIX%\Library\include\eigen3 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MD /O2 /Ob2 /DNDEBUG /showIncludes /Fotest\CMakeFiles\ExogenousConversionsUnitTests.dir\ExogenousConversionsUnitTest.cpp.obj /Fdtest\CMakeFiles\ExogenousConversionsUnitTests.dir\ /FS -c %SRC_DIR%\test\ExogenousConversionsUnitTest.cpp
%SRC_DIR%\test\ExogenousConversionsUnitTest.cpp(243): error C2672: 'matioCpp::make_cell_array': no matching overloaded function found
%SRC_DIR%\test\ExogenousConversionsUnitTest.cpp(243): error C2783: 'matioCpp::CellArray matioCpp::make_cell_array(const std::string &,const iterator &,const iterator &)': could not deduce template argument for '__formal'
%SRC_DIR%\include\matioCpp/ExogenousConversions.h(111): note: see declaration of 'matioCpp::make_cell_array'
%SRC_DIR%\test\ExogenousConversionsUnitTest.cpp(244): error C3536: 'toMatioCellFromSet': cannot be used before it is initialized
%SRC_DIR%\test\ExogenousConversionsUnitTest.cpp(244): error C2109: subscript requires array or pointer type
%SRC_DIR%\test\ExogenousConversionsUnitTest.cpp(245): error C2109: subscript requires array or pointer type
%SRC_DIR%\test\ExogenousConversionsUnitTest.cpp(246): error C2109: subscript requires array or pointer type
[33/35] Building CXX object test\CMakeFiles\StructArrayElementUnitTests.dir\StructArrayElementUnitTest.cpp.obj
ninja: build stopped: subcommand failed.

probably a VS2017 problem.

[traversaro]

Switching to VS2019 solved the build problem. Given conda-forge/conda-forge.github.io#1810, I do not think it is particularly problematic to use VS2019.

[traversaro]

@conda-forge/help-c-cpp The recipe is ready for review.

[h-vetinari]

Can we name this libmatio, see conda-forge/conda-forge.github.io#1073?.

I'm (re)starting to work through some of the xyz-cpp -> libxyz renames, but at least we could avoid adding new ones...

I realize that this package is a bit special because it is literally named matio-cpp, but we have other packages that diverge from their upstream (or PyPI) names as well and for the consistency of the lib* packages, I think this would be a good enough reason IMO. In this particular case, I'd say one could also consider libmatiocpp, as that's the (lower-cased) name of the .so produced on unix.

[traversaro]

The problem is that libmatio already exists (https://github.com/conda-forge/libmatio-feedstock) and is the C library for which matio-cpp provides an idiomatic C++ interface. If you feel strongly about it, I can rename it libmatiocpp, even if I feel that it may be less intuitive for users, but that is ok. Would libmatio-cpp be an option?

[h-vetinari]

If you feel strongly about it, I can rename it libmatiocpp, even if I feel that it may be less intuitive for users, but that is ok.

First off, I'm just one opinion among (potentially) many. Just wanted to add my $0.02.

Would libmatio-cpp be an option?

Given that there really is a distinction between the C & C++ libs, I'd say that's a perfectly fine choice. It also happens to match what LLVM does for libclang vs. libclang-cpp.

[traversaro]

I renamed the package libmatio-cpp.