Pinocchio: v2.1.0 : Build error when hpp-fcl optional dependency is not available

[aelkhour]

pinocchio v2.1.0 does not seem to build when hpp-fcl optional dependency is not available.

[ 73%] Building CXX object bindings/python/CMakeFiles/pinocchio_pywrap.dir/parsers/expose-parsers.cpp.o
cd /home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/bindings/python && /usr/lib/ccache/g++-7  -DPINOCCHIO_WITH_URDFDOM -Dpinocchio_pywrap_EXPORTS -isystem /home/antonio/wdc_workspace/install/pc/wanderpkg/include -I/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build -I/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include -I/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio/include -isystem /usr/include/python2.7 -isystem /home/antonio/wdc_workspace/install/pc/wanderpkg/include/eigen3  -pedantic -Wno-long-long -Wall -Wextra -Wcast-align -Wcast-qual -Wformat -Wwrite-strings -Wconversion -fPIC -w -O3 -DNDEBUG -fPIC   -isystem/usr/include/python2.7 -isystem/home/antonio/.local/lib/python2.7/site-packages/numpy/core/include -o CMakeFiles/pinocchio_pywrap.dir/parsers/expose-parsers.cpp.o -c /home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio/bindings/python/parsers/expose-parsers.cpp
In file included from /home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include/pinocchio/parsers/urdf.hpp:268:0,
                 from /home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include/pinocchio/bindings/python/parsers/parsers.hpp:14,
                 from /home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio/bindings/python/parsers/expose-parsers.cpp:5:
/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include/pinocchio/parsers/urdf/geometry.hxx:294:51: error: ‘pinocchio::fcl::MeshLoaderPtr’ has not been declared
                                              fcl::MeshLoaderPtr& meshLoader,
                                                   ^~~~~~~~~~~~~
/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include/pinocchio/parsers/urdf/geometry.hxx:375:34: error: ‘pinocchio::fcl::MeshLoaderPtr’ has not been declared
                             fcl::MeshLoaderPtr& meshLoader,
                                  ^~~~~~~~~~~~~
In file included from /home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include/pinocchio/parsers/urdf.hpp:268:0,
                 from /home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include/pinocchio/bindings/python/parsers/parsers.hpp:14,
                 from /home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio/bindings/python/parsers/expose-parsers.cpp:5:
/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include/pinocchio/parsers/urdf/geometry.hxx:411:37: error: ‘pinocchio::fcl::MeshLoaderPtr’ has not been declared
                                fcl::MeshLoaderPtr meshLoader)
                                     ^~~~~~~~~~~~~
/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build/include/pinocchio/parsers/urdf/geometry.hxx:429:37: error: ‘pinocchio::fcl::MeshLoaderPtr’ has not been declared
                                fcl::MeshLoaderPtr meshLoader)
                                     ^~~~~~~~~~~~~
bindings/python/CMakeFiles/pinocchio_pywrap.dir/build.make:665: recipe for target 'bindings/python/CMakeFiles/pinocchio_pywrap.dir/parsers/expose-parsers.cpp.o' failed
make[2]: *** [bindings/python/CMakeFiles/pinocchio_pywrap.dir/parsers/expose-parsers.cpp.o] Error 1
make[2]: Leaving directory '/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build'
CMakeFiles/Makefile2:773: recipe for target 'bindings/python/CMakeFiles/pinocchio_pywrap.dir/all' failed
make[1]: *** [bindings/python/CMakeFiles/pinocchio_pywrap.dir/all] Error 2
make[1]: Leaving directory '/home/antonio/wdc_workspace/build/pc/wanderpkg/SOUP/pinocchio/src/pinocchio-build'
Makefile:143: recipe for target 'all' failed

I've seen that there are #ifdef PINOCCHIO_WITH_HPP_FCL lying around in the code which could help fix this, but I'm not sure how to deal with this error as a hpp-fcl type is passed in the function signature.

[jcarpent]

It has been fixed on the devel branch which will be released soon (next week). Is it fine for you?

[aelkhour]

Yes perfect, thanks !

[aelkhour]

By the way, would you consider making a more complete CI pipeline (typically covering the case of missing dependencies) for the releases ?

[jcarpent]

It would be essential, but it would make explosive the number of CI instances. On Gitbal, we are already checking 16 different configurations (Ubuntu versions + Debug or Release + Python 2 or 3) which reach the limits I think.

[gabrielebndn]

I think we should have at least one build without any dependency (except for Python-related stuff). For this one, we don't need to go through all the combinations of Ubuntu versions, Debug vs Release, Python 2 vs 3, nor through all the combinations of possible dependencies. Just one will be enough to catch (most) bugs like this one. It is not the first time it happens.

[jcarpent]

You're right!

[jmirabel]

In the same vein, is it relevant to compile both in debug and release for all the combination ?

[jcarpent]

It depends, because some bugs are appearing only in debug mode, for certain distributions only!

[nim65s]

https://gepgitlab.laas.fr/gsaurel/hpp-pinocchio/pipelines/3686 worked on 16.04-debug, 16.04-release, 18.04-release and failed in 18.04 debug.

But maybe when we can easily have errors in debug and not in release, the other way is far less usual.

[jmirabel]

It depends, because some bugs are appearing only in debug mode, for certain distributions only!

Any reason to compile in release mode then ?

[nim65s]

We can still have some class of errors only in release mode. Plus running tests can be an order of magnitude faster.

[jmirabel]

Plus running tests can be an order of magnitude faster.

Removing compilation in release mode will make it faster, because, currently, you are running them anyway.

We can still have some class of errors only in release mode.

The question is whether those errors are more important that with / without hpp-fcl... CI should target first what matters the most. We may have two layers of CI. One light on devel branch and one heavier on master.

[gabrielebndn]

worked on [...] 18.04-release and failed in 18.04 release

@nim65s I think this is I typo. From what you said afterwards, I guess you meant it was working on release and failing in debug?

[nim65s]

Jobs are running in parallel, so no, if we remove the faster, the slower will not finish earlier. And if you made a typo, you would be glad to know it in 3min instead of 30min, be able to cancel all the slower builds, push the fix and continue what you were doing.

[jmirabel]

Jobs are running in parallel

you have no control for this on Travis. They may but they may not.

if you made a typo

Compilation should be faster in debug than in release.

[nim65s]

you have no control for this on Travis

I was thinking about gitlab. On pinocchio there are only 2 builds (16.04 & 18.04) on travis.

Compilation should be faster in debug than in release.

This is true for the build time, I was thinking about test time, but you are right.

[nim65s]

So what should we do on Gitlab ? Build everything in devel, then add only one job in release, and one other job with only the required dependencies and not the optional ones ?

Vote with :+1: / :-1: :)

[wxmerkt]

But maybe when we can easily have errors in debug and not in release

All Eigen assert (e.g. resizing or wrong access via segment) are disabled in Release.

[jmirabel]

We may want to do something different in branch devel and master. We don't really care if master takes some time. We do if devel does.

[jcarpent]

I'm doing some modifications on the way we integrate dependencies.
I want to remove the notion of OPTIONAL to make then either active or inactive.

Then, for Travis, I'm also checking that everything goes fine on devel branch with and without hpp-fcl

[nim65s]

We may want to do something different in branch devel and master. We don't really care if master takes some time. We do if devel does.

Then all I have to do is to add only: master in all the builds we don't want to test anymore on devel.
But we should not do something special "if we are on devel", because we don't want to work only on devel, but usually we create other branches.

This is the reason why I was not able to split the PR https://github.com/humanoid-path-planner/hpp-doc/pull/46 : the CI run only if the branch is named "devel"

[jcarpent]

But the merges are only on the base branches: master or devel. So everything goes fine.

[gabrielebndn]

What? Why dropping the checks on devel? We always work on devel! Master is usually simply updated from master. Checking devel will allow to catch errors much earlier.

[jmirabel]

We are not talking about dropping the checks. As you say, we always work on devel. We want to avoid time increase of the checks on this branch (or on branch different from master). Compiling only in debug mode won't miss most of the bugs and will make checks faster.

[jcarpent]

I've fixed the main concerns of this issue via #744.
I will close this issue. Feel free to reopen it needed.