Since the Octomap package provides CMake configs suitable for
cross-compilation there's no need for an external module
in cmake-modules.

Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>

With the latest update of octomap the CMake module
Findoctomap is not needed anymore.

Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>

Also backport a patch improving generation of config.cmake
files. This makes octomap libraries relocatable which is
required for successful cross-compilation builds.

Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>

Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>

Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>

Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>

The patch added in the reverted commit was meant to fix the issue
https://github.com/bmwcarit/meta-ros/issues/291



In fact it enables CMake to look for libraries in a host system which
leads to errors when a path is tested for a library presence with the
help of CMake's find_library() command: e.g. a non-existing host
directory is tested for library presence and find_library() returns
successfully because the library exists in bitbake's sysroot; then the
directory is used by the linker, but the library doesn't exist in the
directory -> failure. In worse cases the host directory may actually exist
and contain the library, but of wrong architecture, format or
incompatible ABI making finding the root cause a difficult task.

Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>

Use the latest indigo release (0.17.4).

Use the latest indigo release (0.17.4).

Authors: JochiPochi <john.aleman@cyphyworks.com>
         Gustavo Jose de Sousa <gustavo.sousa@intel.com>

A patch for the config file is also necessary because the include directory
path was being hardcoded in the generated file, which caused problems for cross
compilation. That patch has already been applied on upstream but for a newer
version, so we're backporting it here.

Apparently, the Kinetic release for this package is supposed to work fine with
indigo distribution. That could be tried later, so that we can get rid of the
local patch.

Authors: JochiPochi <john.aleman@cyphyworks.com>
         Gustavo Jose de Sousa <gustavo.sousa@intel.com>

As ar-track-alvar has been repaired, we can add this recipe back
to packagegroup-ros-world.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

ar_track_alvar 0.5.x only support opencv2, whereas meta-oe provides
opencv3. The ar_track_alvar kinectic versions 0.6.x also support
opencv3, as pointed out in the comment of commit e82747c4 [1].

Therefore, this commit updates ar-track-alvar to version 0.6.1
to resolve #397.

[1] https://github.com/sniekum/ar_track_alvar/commit/e82747c42df3ead0d45bcd84048f6baef04b9f67

.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

bitbake diagnostic-aggregrator failed due to missing build
dependencies with:
```
| -- Could not find the required component 'bondcpp'. The following CMake error indicates that you either need to install the package with the same name or change your environment so that it can be found.
| CMake Error at /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/qemux86/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
|   Could not find a package configuration file provided by "bondcpp" with any
|   of the following names:
|
|     bondcppConfig.cmake
|     bondcpp-config.cmake
|
|   Add the installation prefix of "bondcpp" to CMAKE_PREFIX_PATH or set
|   "bondcpp_DIR" to a directory containing one of the above files.  If
|   "bondcpp" provides a separate development package or SDK, be sure it has
|   been installed.
| Call Stack (most recent call first):
|   CMakeLists.txt:6 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
```

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

Compiling rosconsole failed with:
```
[...]/ros_comm-1.11.20/tools/rosconsole/include/ros/console.h:121:14: error: 'vector' in namespace 'std' does not name a template type
 typedef std::vector<TokenPtr> V_Token;
```

The console.h assumed that vector is included already by one of its
dependencies. This bold assumption has been uncovered by the update
of the boost library to version 1.62.0 [1, 2] in openembedded-core
repository.

Coincidently, this issue was also noticed by ROS users on Gentoo and
Arch Linux, which probably also use the latest boost library and gcc6,
and they opened pull requests on the indigo and kinetic branches [3, 4, 5]
with commits to address the issue. The patch in the kinetic branch has
been merged, the others to the indigo branch have been rejected as the
ros-comm maintainers intend to simply backport the patch from the
kinetic branch for the next release.

This commit applies the patch merged in the kinetic branch in our
recipe for the current indigo release version.

[1] http://cgit.openembedded.org/openembedded-core/commit/?id=c31030d87cd1741a4186d711325b8eab9c70b327
[2] http://cgit.openembedded.org/openembedded-core/commit/?id=42b4fa2f923244bc047874752d2e0381ff6f0a25
[3] https://github.com/ros/ros_comm/pull/911
[4] https://github.com/ros/ros_comm/pull/930
[5] https://github.com/ros/ros_comm/pull/939



Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

This commit removes the patch that has been accepted upstream
and has been included in the version 1.5.45.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

In 2014, the update of the diagnostics recipes from 1.8.3 to 1.8.4
failed due to reasons that seem not to be relevant anymore in the
current version 1.8.10. As the diagnostic-aggregator recipe failed
with gcc6 (cf. https://github.com/bmwcarit/meta-ros/issues/392

),
I revisited the diagnostics recipes and this commit updates them.
The current diagnostics recipes in version 1.8.10 do not fail with
gcc6, and is one step forward to build meta-ros with gcc6.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

The meta-oe provides since commit 8700ba38@openembedded/meta-openembedded
(commit date: 2016-01-14) [1] a recipe for the POCO C++ Library.
Consequently, this commit removes the libpoco recipe in the
meta-ros layer.

As meta-ros already depends on the meta-oe layer, the poco
recipe is available in release version since 2016-01-14,
and the poco recipe in meta-ros is redundant for these versions.
However, this commit still provides the currently latest poco
recipe [2] for users that are not using a recent version of the
meta-oe layer.

[1] http://cgit.openembedded.org/meta-openembedded/commit?id=8700ba38804af3c27f3662737f679afa1bdc86da
[2] http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/poco?id=0a2bd4f9784253a8a8dda35e3c4dbd75931d3564



Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>

The recent versions of the rosbridge_library package does not depend
on python-pytz anymore. So, this commit removes the dependency in
the recipe file and removes the now unneeded python-pytz recipe.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>