Due to the update, this commit drops the patch that is not
needed anymore. A slightly different patch has been merged.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the update, this commit also drops both patches that are
now included in the released version.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Due to the uodate, this commit also adjusts the LIC_FILES_CHKSUM
line to the recent change in package.xml.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
libeigen is an interface dependency needed by orocos-kdl and
orocos-kdl does export this dependency, but it does so with
a hardcoded absolute path pointing to the sysroot where
orocos-kdl was built. In case the sysroot doesn't exist
the compiler can't find libeigen's headers.
Unfortunately orocos-kdl's CMakeList.txt doesn't use
per-target include dirs, but global ones. I don't know
an easy way how to make them relocatable.
The easiest way to fix it is to add the explicit dependency
on libeigen to kdl-parser's CMakeList.txt. Anyway it's already
been declarated as a dependency in kdl-parser's recipe.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
If a package (A) depends on another package (B) and the package
B depends on Boost then it might happen that B produces BConfig.cmake
file where absolute paths to Boost's headers are put (because CMake's
standard FindBoost.cmake module reports absolute paths). In case of
Yocto it means that BConfig.cmake will contain something like
/path/to/build/tmp-glibc/work/i586/package_B/0.0.1/recipe-sysroot/usr/include.
The path may not exist at the moment when the package A is being built.
And that leads to the failure of the check this patch switches off.
The problem has been reported to catkin's issue tracker:
https://github.com/ros/catkin/issues/851
This patch "relocates" required headers from dependencies' sysroots
to the current sysroot by removing sysroot prefix from include dirs
in *Config.cmake files at the moment the files get created and
by prepending the include dirs again with the current sysroot prefix.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Octomap has been updated to provide relocatable libraries. Now
it's not needed to tweak the absolute paths to Octomap's
binaries.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
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>
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>
Without the dependency on cmake-modules, `bitbake pcl-conversions` can
possibly fail with:
```
| CMake Error at /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/sysroots/x86_64-linux/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
| Could not find a package configuration file provided by "cmake_modules"
| with any of the following names:
|
| cmake_modulesConfig.cmake
| cmake_modules-config.cmake
|
| Add the installation prefix of "cmake_modules" to CMAKE_PREFIX_PATH or set
| "cmake_modules_DIR" to a directory containing one of the above files. If
| "cmake_modules" provides a separate development package or SDK, be sure it
| has been installed.
| Call Stack (most recent call first):
| CMakeLists.txt:4 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
```
The failure only occurs if cmake-modules has not been installed
before pcl-conversions is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`,
which builds many packages in parallel, did not
uncover this because cmake-modules was usually installed before
pcl-conversions was configured.
However, the issue is clearly reproducable with
`bitbake pcl-conversions cmake-modules -c cleanall && bitbake pcl-conversions`
The missing dependency was probably introduced by the automatic
recipe updates without checking for new dependencies.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Without the dependency on cmake-modules, `bitbake eigen-conversions`
can possibly fail with:
```
| CMake Error at /home/lukas/dev/openembedded.org/openembedded-core/build/tmp-glibc/work/i586-oe-linux/eigen-conversions/1.11.8-r0/recipe-sysroot-native/opt/ros/indigo/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
| Could not find a package configuration file provided by "cmake_modules"
| with any of the following names:
|
| cmake_modulesConfig.cmake
| cmake_modules-config.cmake
|
| Add the installation prefix of "cmake_modules" to CMAKE_PREFIX_PATH or set
| "cmake_modules_DIR" to a directory containing one of the above files. If
| "cmake_modules" provides a separate development package or SDK, be sure it
| has been installed.
| Call Stack (most recent call first):
| CMakeLists.txt:5 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
```
The failure only occurs if cmake-modules has not been installed
before eigen-conversions is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`, which
builds many packages in parallel, did not uncover this because
make-modules was usually installed before eigen-conversions was
configured.
However, the issue is clearly reproducible with
`bitbake eigen-conversions cmake-modules -c cleanall && bitbake eigen-conversions`
The missing dependency was probably introduced by the automatic
recipe updates without checking for new dependencies.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Without the dependency on libeigen, `bitbake eigen-stl-containers`
can possibly fail with:
```
| CMake Error at CMakeLists.txt:8 (find_package):
| By not providing "FindEigen3.cmake" in CMAKE_MODULE_PATH this project has
| asked CMake to find a package configuration file provided by "Eigen3", but
| CMake did not find one.
|
| Could not find a package configuration file provided by "Eigen3" with any
| of the following names:
|
| Eigen3Config.cmake
| eigen3-config.cmake
|
| Add the installation prefix of "Eigen3" to CMAKE_PREFIX_PATH or set
| "Eigen3_DIR" to a directory containing one of the above files. If "Eigen3"
| provides a separate development package or SDK, be sure it has been
| installed.
|
|
| -- Configuring incomplete, errors occurred!
```
The failure only occurs if libeigen has not been installed
before eigen-stl-containers is configured. Hence, the regular
regression testing with `bitbake core-image-ros-world`,
which builds many packages in parallel, did not uncover this
because libeigen was usually installed before
eigen-stl-containers was configured.
However, the issue is clearly reproducible with
`bitbake eigen-stl-containers libeigen -c cleanall && bitbake eigen-stl-containers`
The missing dependency was probably overlooked in the creation of
the eigen-stl-containers recipe, i.e., in
commit a255e67c9e.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.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>
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] e82747c42d.
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 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>
Bitbake gives a dependency error when IMAGE_FEATURES += " dev-pkgs" is set.
This is because the urdfdom-headers package contains headers only, as a
result bitbake packages them into urdfdom-headers-dev and leaves
urdfdom-headers empty.
Since there are no files to be packaged into urdfdom-headers bitbake
doesn't create the package. urdfdom-headers is a dependency
of urdfdom-headers-dev by default so bitbake errors when building an image
with dev-pkgs enabled.
ALLOW_EMPTY tells bitbake to create a package even when nothing is in it.
This resolves the dependency issue of urdfdom-headers-dev
http://www.embeddedlinux.org.cn/OEManual/recipes_packages.html
While testing the version updates, I noticed that the
camera-calibration-parsers were missing the roscpp dependencies,
and hence do_configure failed with:
```
| Could not find a package configuration file provided by "roscpp" with any
| of the following names:
|
| roscppConfig.cmake
| roscpp-config.cmake
|
| Add the installation prefix of "roscpp" to CMAKE_PREFIX_PATH or set
| "roscpp_DIR" to a directory containing one of the above files. If "roscpp"
| provides a separate development package or SDK, be sure it has been
| installed.
| Call Stack (most recent call first):
| CMakeLists.txt:4 (find_package)
|
|
| -- Configuring incomplete, errors occurred!
```
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
This patch fixes the continuous integration test by dropping
the sound-play recipe from ros-world, as it would fail with
the master branches (addresses issue #388).
https://github.com/bmwcarit/meta-ros/issues/388
In _setup_util.py.in, we use python provided by environment instead of
the generated one, as the generated python path can be arbitrarily long
(depending on the location of the build directory), and hence reaches
the shebang line limit, causing the script to fail at start-up.
The catkin developers changed the cmake-generated template _setup_util.py
to use @PYTHON_EXECUTABLE@ instead of /usr/bin/env python in changeset
bf12b40c2 [1]. We revert this change here to address the issue #384 [2].
[1] bf12b40c2a
[2] https://github.com/bmwcarit/meta-ros/issues/384
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
This commit adds recipes for rosbridge_suite and its dependencies.
Its main content is based on the commits of pull request #364 by
Christoph Schultz.
As maintainer, Lukas Bulwahn just included the contributions
with a proper commit message, added the new packages to the
packagegroup-ros-world, and slightly improved the line breaking.
The internal CI build detected that bitbake robot-state-publisher
fails after the recent version update. Hence, this commit adjusts
the dependencies to those dependencies stated in the package.xml.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
Some of the gst-plugins-good modules were missing to setup a cam for some basic scenarios/tutorials. I added it so they'll be added to the default build set.
The openslam_gmapping commit
07b0c7ef62
corrects the license information of that package, and hence, we
adjust the recipe in meta-ros accordingly.
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
This commit drops all patches as they have been merged upstream
since 0.9.1. Furthermore, this commit completes the dependencies
of the velocity_controllers and the forward_command_controller
package.
The ROS packages, rosgraph_msgs and std_srvs, previously
in the ros_comm repository, have been moved into a separate
ros-comm-msgs repository for the ROS indigo distribution.
This commit:
- removes std-srvs and rosgraph-msgs recipes, as their sources
now are located in the ros_comm_msgs repository.
- adds a recipe for the new roslz4 package, which rosbag-storage
depends on.
- removes the patch that has been merged upstream.
The resource_retriever package's source was moved into
its own repository, and needs now python-urlgrabber.
Hence, this commit provides the recipe for python-urlgrabber, moves
the resource-retriever to its own location, and updates all other
packages in the robot_model repository.
Lukas Bulwahn