Compilation and tests fail with clang

[bchretien]

On Travis, metapodfromurdf leads to a segmentation fault when using clang 3.4:

[ 18%] Generating include/metapod/models/simple_arm/config.hh, include/metapod/models/simple_arm/simple_arm.hh, include/metapod/models/simple_arm/simple_arm.cc

metapodfromurdf/metapodfromurdf --name simple_arm --libname metapod_simple_arm --directory /home/travis/build/laas/metapod/_travis/build/include/metapod/models/simple_arm --config-file /home/travis/build/laas/metapod/data/simple_arm.config --license-file /home/travis/build/laas/metapod/data/metapod_license_file.txt /home/travis/build/laas/metapod/data/simple_arm.urdf

make[2]: *** [include/metapod/models/simple_arm/config.hh] Segmentation fault

Also, locally, when using clang 3.5.0, I get a bunch of elaborated type refers to a typedef errors:

In file included from .../metapod/build_clang/include/metapod/models/simple_arm/simple_arm.cc:31:
.../metapod/build_clang/include/metapod/models/simple_arm/simple_arm.hh:58:3: error: elaborated type refers to a typedef
  METAPOD_TYPEDEFS;
  ^
.../metapod/include/metapod/tools/joint.hh:32:3: note: expanded from macro 'METAPOD_TYPEDEFS'
  EIGEN_METAPOD_TYPEDEFS; \
  ^
.../metapod/include/metapod/tools/fwd.hh:62:42: note: expanded from macro 'EIGEN_METAPOD_TYPEDEFS'
  typedef struct Vector1dTpl<FloatType>::Type Vector1d;      \
                                         ^
.../metapod/build_clang/include/metapod/models/simple_arm/simple_arm.cc:36:31: note: in instantiation of template class 'metapod::simple_arm<double>' requested here
template <> const std::string simple_arm<FloatType>::Node0::joint_name = std::string("SHOULDER");
                              ^
.../metapod/include/metapod/tools/fwd.hh:32:44: note: declared here
  { typedef Eigen::Matrix<FloatType, 1, 1> Type; };
                                           ^

[bchretien]

It seems to be related to #72, although there can be differences between Linux and OSX outputs when using clang. The new Travis OSX support could certainly be useful.

[bchretien]

Other error (happens to Node0, Node1 ...):

In file included from .../metapod/build_clang/include/metapod/models/simple_arm/simple_arm.cc:31:
In file included from .../metapod/build_clang/include/metapod/models/simple_arm/simple_arm.hh:40:
.../metapod/include/metapod/tools/initnufwddyn.hh:49:94: error: no member named 'parent_id' in 'metapod::simple_arm<double>::Node0'
    static const bool value = internal::updateNuOfFwdDynFromParentOrLocal<Robot, Node, Node::parent_id>::value;
                                                                                       ~~~~~~^
.../metapod/build_clang/include/metapod/models/simple_arm/simple_arm.hh:94:41: note: in instantiation of template class
      'metapod::initNuFwdDyn<metapod::simple_arm<double>, metapod::simple_arm<double>::Node0>' requested here
    static const bool jointNuOfFwdDyn = initNuFwdDyn< simple_arm<FloatType>, simple_arm<FloatType>::Node0 >::value; // subtree supported by at least on...
                                        ^
/usr/include/boost/fusion/container/vector/detail/preprocessed/vector10.hpp:374:12: note: in instantiation of member class 'metapod::simple_arm<double>::Node0'
      requested here
        T0 m0; T1 m1; T2 m2;
           ^
/usr/include/boost/fusion/container/vector/detail/preprocessed/vector10.hpp:378:9: note: in instantiation of template class
      'boost::fusion::vector_data3<metapod::simple_arm<double>::Node0, metapod::simple_arm<double>::Node1, metapod::simple_arm<double>::Node2>' requested here
      : vector_data3<T0 , T1 , T2>
        ^
.../metapod/build_clang/include/metapod/models/simple_arm/simple_arm.hh:169:14: note: in instantiation of template class
      'boost::fusion::vector3<metapod::simple_arm<double>::Node0, metapod::simple_arm<double>::Node1, metapod::simple_arm<double>::Node2>' requested here
  NodeVector nodes;
             ^
.../metapod/build_clang/include/metapod/models/simple_arm/simple_arm.cc:36:31: note: in instantiation of template class 'metapod::simple_arm<double>'
      requested here
template <> const std::string simple_arm<FloatType>::Node0::joint_name = std::string("SHOULDER");

[bchretien]

And a more problematic one:

.../metapod/include/metapod/tools/initnufwddyn.hh:34:52: error: in-class initializer for static data member is not a constant expression
    static const bool value = Node::jointFwdDyn || Parent::jointNuOfFwdDyn;
                              ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~

Both are static const bool, but that does not seem enough for clang:

static const bool jointFwdDyn = false; // <dynamics> fwd_dyn field, used by chda
static const bool jointNuOfFwdDyn = initNuFwdDyn< simple_arm<FloatType>, simple_arm<FloatType>::Node0 >::value; // subtree supported by at least one fwdDyn joint

[olivier-stasse]

Thanks Benjamin. I will look into that.

[olivier-stasse]

Hi Benjamin,
Unfortunately clang and boost (1.48.02) seems not be compatible in ubuntu 12.04 LTS.
More precisely I am having error on filesystemv3.
I will see later if this occurs in 14.04 LTS.

[olivier-stasse]

Dear Benjamin,
After several trials I did not find a proper way to test metapod with clang on Ubuntu 14.04 LTS and Ubuntu 12.04 LTS.
Do you thing that travis can handle it ?
(I have no experience on continuous integration with Travis on MacOS)

[bchretien]

What we did with RobOptim is first fix clang errors on Linux since this is something we can check on our systems locally, then enable Mac OS X in the build matrix on Travis, since AFAIK only Thomas could test it locally. jrl-travis supports the osx target (you can check RobOptim's .travis.yml), just remember to properly set HOMEBREW_DEPENDENCIES and add osx to os.

It was in beta back then and we had to ask them to enable it, but I guess it's officially released now.

Also, we compile for both gcc and clang on osx, and since gcc is just a front-end for clang on that system, we explicitly rely on gcc-4.8. If that compiles and runs fine on Travis, that may give OS X users a temporary workaround.

[francois-keith]

@bchretien I think you still have to ask for the test on mac OSX.
I tried a while ago to get it to change the .travis.yml to make it run on mac OSX on my fork (ie changing the .travis.yml file + using jrl-travis submodule) but it didn't seem that this modification only can do the trick.
EDIT: see the corresponding travis there

[bchretien]

@francois-keith ok, I guess they're still ironing a few things out. Thanks for the link!