Pinocchio: support MSVC compiler

[sbarthelemy]

Hello.

I'm trying to get pinocchio working on Windows (only the core lib, not the bindings), compiled with MSVC.
I'm making some progress, but for the support to be sustainable, some CI would be needed.
I think the CI could be provided by appveyor, but I doubt the current cmake scripts, based on PkgConfig will work on Windows.

I'm thinking of adding another build system (either raw modern CMake, meson or qibuild) , in addition to jrl-cmake.

What is your opinion on this?

[jcarpent]

Dear @sbarthelemy ,

First of all, thanks for the great effort you're providing to support Pinocchio on Windows.
I'm totally OK for adding a CI for Windows build. Either appveyor or Action by GitHub which will be open to everyone soon (13rd of November).

For the packaging of the project, I think a modern CMake is definitely the right option and I was thinking of it for a while because jrl-cmake is helpful, but a bit too heavy for Pinocchio.

Do you have some official branches on which you are making your updates?

Thanks again for your collaboration to the project!

[nim65s]

Hi,

First, yes, supporting windows and setting a CI on it would be really nice, thanks !

About the method, I don't see why modern CMake would be incompatible with the JRL-cmakemodule, as I'm using 3.15.

I also don't understand how you plan to add a raw modern CMake while keeping the JRL-cmakemodule ;
or if you want to remove the JRL-cmakemodule and use only a modern CMake (I guess this is what you mean), which version are you targeting, and what do you plan for guys (and robots) stuck in 2.8.

Also, working on the CMake of Pinocchio to support more OS implies to port this work back into eigenpy & hpp-fcl, and I find it really convenient to maintain this work in only one place instead of 3, and this is why we have a cmake module.

Once again, I think we should define a clear roadmap of supported versions of Python, Boost, Eigen, CMake, C++, etc., maybe by looking at the OS and their versions we want to support.

I mean I'm totally OK to support newer versions of those tools, but if we also want to support older ones, we must define until when we will support them, otherwise we are just spending all our time trying to support everything.
Maybe you find the JRL-cmakemodule bloated and too heavy (at least, I do ; I really prefer simple code), but I think this is mainly because we have not defined a roadmap in it, and therefore we never know when we can remove support for a combination of old stuff, so the codebase keeps growing for no reasons.

[francois-keith]

Hi,

Thank you for porting pinocchio on MSVC.

Just putting my two cents: using the clang compiler of MSVC16 allowed me to compile pinocchio with only very little cmake modifications (I tried compiling it with the native msvc compilers, but it required much more code modifications).

Also, concerning pkg-config on visual, we used to have an appveyor build for roboptim-core, but it is a bit dated, so I don't if it would still work with up-to-date submodules.

[jcarpent]

Dear @francois-keith,

Thanks a lot for joining the discussion. To go a bit more into the details, could you provide access to the code you have modified for porting Pinocchio on Windows. As you're a member of the stack-of-tasks, you may create a dedicated branch on the official repository.

Thanks in advance,

Justin

[sbarthelemy]

Hello all, thank you for the feedback and welcoming messages!

I'm answering the various questions in one go.

I'm totally OK for adding a CI for Windows build. Either appveyor or Action by GitHub which will be open to everyone soon (13rd of November).

Thank you for the hint at github actions! I'm giving it a try. It seems more convenient than appveyor as it supports Mac OS in addition to Windows and Ubuntu.

Do you have some official branches on which you are making your updates?

not yet, I'll publish it as soon as a subset builds on CI.

About the method, I don't see why modern CMake would be incompatible with the JRL-cmakemodule, as I'm using 3.15.

I feared that pkg-config would be hard to make work on Windows.

I tried today, using the pkg-config.bat which is pre-installed on github's windows-2016 VMs.
I had to patch FindPkgConfig.cmake to make it work, which does not seem acceptable :-/. I'll keep trying a bit.

By "modern cmake", I meant relying on CMake itself (through the "modern" import target feature) in order to deal with dependencies.

I also don't understand how you plan to add a raw modern CMake while keeping the JRL-cmakemodule ;
or if you want to remove the JRL-cmakemodule and use only a modern CMake (I guess this is what you mean)

I think a "modern cmake" approach could coexist with jrl-cmake. Eg. depending on an option, the main CMakeList.txt could include different files. But I did not try.

Just putting my two cents: using the clang compiler of MSVC16 allowed me to compile pinocchio with only very little cmake modifications

Sadly, I'm not currently in the position of choosing the compiler (nor the OS), but
this is good to know, thank you!

[olivier-stasse]

Dear @sbarthelemy
They are discussions about creating CMake Target ( see https://github.com/jrl-umi3218/jrl-cmakemodules/issues/247) , would that solved your problem with pkg-config ?

[sbarthelemy]

Hi again,

They are discussing about creating CMake Target ( see jrl-umi3218/jrl-cmakemodules#247) , would that solve your problem with pkg-config ?

Yes, I suspect that cmake's export targets would be better/easier than pkg-config on Windows.
It is nice if jrl-cmakemodules embraces them.
@olivier-stasse : Thank you for the link! I'll follow the thread.

However, since Francois showed that pkg-config had worked (at least once) on Windows already, I tried the pkg-config way. Here is an update.

I could get perl-provided pkg-config.bat working on my windows 2016 VM, but not on github's own windows-2016 VM: it fails to import Pod/Usage.pm for some reason.
Since installing pkgconfiglite worked, it did not dig further into using the perl version.

I now have a (single) pinocchio test building successfully on github action.
It is using same version of boost (1.64.0) and of the MSVC compiler (v140) that we currently use at SBRE.

The test crashes when running, I had no time to dig into it yet. Maybe because it fails to find the DLLs?

I also noticed that github will remove the windows-2016 VM I'm currently using on the 7th of November (in two days!). So I'll need to try again using their windows-2019 VM. This is bad news since the compiler version I prefer (v140) is not preinstalled on this VM, and also because I don't have a local windows-2019 VM/computer.

[sbarthelemy]

Hi again,

the test now passes on Windows. It is there:
https://github.com/sbarthelemy/pinocchio/commit/ad525407370265f69926d9d15715266e6e8e343b/checks?check_suite_id=298567012

Feedback is welcomed!

The next steps are to get it working on windows-2019 and maybe to factor the powershell code between vagrant and github-action.

Cheers

[jcarpent]

Very nice @sbarthelemy. Small question, why the current job is failing on 16.04? It seems that you've forced a C++11 compilation flag somewhere but I was not able to see it in your modifications.

[sbarthelemy]

Very nice @sbarthelemy.

Thanks!

Small question, why the current job is failing on 16.04? It seems that you've forced a C++11 compilation flag somewhere but I was not able to see it in your modifications.

It is weird indeed, I'll look into it.

[sbarthelemy]

Small question, why the current job is failing on 16.04?

When I replaced IF(UNIX) with IF(${PROJECT_NAME}_SOURCES),
I though it would not change anything for the ubuntu runners.
I was wrong: those runners compile with BUILD_WITH_LUA_SUPPORT==OFF, and (surprisingly) the other options (urdf, python,...) do not contribute any non-header source file and ${PROJECT_NAME}_SOURCES is empty.

So I "fixed" it with IF(${PROJECT_NAME}_SOURCES OR UNIX) for now.

It seems that you've forced a C++11 compilation flag somewhere but I was not able to see it in your modifications.

Does pinocchio support C++03? The readme says "C++11/14/17/20 compliant."

It would be nice to leverage some C++11 features (eg. std::chrono in place of non-portable gettimeoday).

By the way, @francois-keith thank you for publishing the vs16_clang branch!

[jcarpent]

@sbarthelemy Thanks for the quick answer.

Does pinocchio support C++03? The readme says "C++11/14/17/20 compliant."

Yes, we support C++ 98/03/11/14/17/20. We plan in some future to only supports C++11 and more and provide some huge simplification of the codes with this respect.
Currently, unfortunately, and because they might be some users still using C++98 (16.04 user for instance), we need to maintain the portability of the code.

[mklvcm]

Hey guys, I just tried to build Pinocchio on Windows and it complains it cannot find eigen3.
I have eigen3 v3.3.7 in "C:Progream Files\eigen3" folder and it builds just fine by the way.
I use pkg-config.exe from pkg-config-lite.
Any suggestions please?

[jcarpent]

I think @sbarthelemy and @francois-keith are the best to provide guidance to your issue.

[francois-keith]

Hi @mklvcm

Is eigen3 found by pkg-config ?
What is the result of the following command ?

pkg-config.exe --print-errors "eigen3 >= 3.0.5" --cflags

If the answer is something similar to this

Package eigen3 was not found in the pkg-config search path.
Perhaps you should add the directory containing `eigen3.pc' to the PKG_CONFIG_PATH environment variable
No package 'eigen3' found

You should set the variable PKG_CONFIG_PATH, either as an environment variable or locally in your terminal.

set PKG_CONFIG_PATH=%PKG_CONFIG_PATH%;D:/dependencies/eigen-3.3.7/share/pkgconfig/

And do the same for the other dependencies (urdfdom_headers, control-toolbox, tinyxml if I am not mistaken).

Please note that depending on the visual studio version and compiler you want to use, it would be better to use

• the branch vs16_clang of this repo if you're compiling with clang on Visual Studio 2016. You'll need to install the clang compiler for Visual Studio, and specify the "ClangCl" Toolset in cmake to this purpose (

  cmake.exe -G"Visual Studio 16 2019"  -A x64  -T"ClangCl"

  )
• the branch sbarth_action of @sbarthelemy 's fork (here) if you're compiling with Visual Studio 2015

[jcarpent]

Solved by #1218.

[traversaro]

If someone needs support not only for MSVC compilation with the ClangCl toolset, but also with the default v142 toolset, I was able to compile pinocchio and its tests successfully (warnings: compilation is quite slow), with the modifications in https://github.com/stack-of-tasks/pinocchio/compare/devel...traversaro:support-msvc-v142 . However, except for the enabling of /bigobj, the other modifications seems to be workaround over MSVC problems, so it is probably better to avoid to merge them in the master or devel branch.

I tested this modifications with MSVC 16.7 Preview 4 and the dependencies installed with vcpkg (./vcpkg install --triplet x64-windows boost-test boost-utility eigen3 urdfdom boost-test boost-utility eigen3 urdfdom boost-format boost-property-tree boost-random), and with options -DBUILD_WITH_URDF_SUPPORT=OFF -DBUILD_PYTHON_INTERFACE=OFF.

cc @S-Dafarra @GiulioRomualdi