Open bchretien opened 9 years ago
It seems to be related to https://github.com/laas/metapod/issues/72, although there can be differences between Linux and OSX outputs when using clang. The new Travis OSX support could certainly be useful.
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");
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
Thanks Benjamin. I will look into that.
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.
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)
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.
@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
@francois-keith ok, I guess they're still ironing a few things out. Thanks for the link!
On Travis,
metapodfromurdf
leads to a segmentation fault when using clang 3.4:Also, locally, when using clang 3.5.0, I get a bunch of
elaborated type refers to a typedef
errors: