NFD

No objections.

Small follow up. There is a small problem that blocks the transition. The trusty instance comes with multiple version of python installed with effect that python and sudo python refer to different versions of python. Somehow, this doesn't work well with waf and I'm investigating why.

python and sudo python refer to different versions of python

Can we run pyenv and sudo pyenv to select the same version for both?

The build matrix added in ndn-cxx commit ce306cae09cc7c249f7311a461e090d414e549d5 includes linux+clang, but nothing sets CXX=clang++ in the build script, so it ends up using gcc...

Ehm... There is this statement

    - os: linux
      dist: trusty
      compiler: clang

Which suppose to be processed by Travis and set clang as a default compiler. Or I could misunderstood what "compiler" directive does.

I think this is happening because of language: generic, which was a workaround of python versioning issue...

All I'm saying is that for some reason, waf is not picking up the compiler that travis sets as default. Maybe it would be enough to add CXX=g++ and CXX=clang++ to the build matrix.

What about NFD?

For NFD I can submit the patch, but it will be failing until we fix all the test cases to ignore IPv6 when it is not available.

Well, it's already failing so...

Any guess on clang error https://travis-ci.org/cawka/NFD/jobs/116233171 ?

Alex Afanasyev wrote:

Any guess on clang error https://travis-ci.org/cawka/NFD/jobs/116233171 ?

Asio bug. It fails to detect that clang does support std::array, so the buffer() overloads that take a std::array are not defined. Search for BOOST_ASIO_HAS_STD_ARRAY in asio/detail/config.hpp. It's fixed in later boost versions, and it doesn't trigger on OSX because there's a specific check for libc++.

I guess we can add -DBOOST_ASIO_HAS_STD_ARRAY as a workaround. I don't have a better solution at the moment.