rock-core/package_set

Package definition for autoproj, to build all the packages that form the core of Rock, the Robot Construction Kit

rock.core package set

This installs the Rock toolchain and associated packages. In an autoproj bootstrap, this package set is selected by adding the following in the package_sets section of autoproj/manifest:

package_sets:
- github: rock-core/package_set

Note for developers

Part of the Rock behavior is not standard autoproj behavior (flavors, C++11 selection logic, …). Complex logic should be isolated within the rock/ folder, and when possible tests should be written in tests/

Use rake test to run all the tests. To run a single test, one needs to run from the package set root and add -I. to the ruby command line, e.g.

ruby -Itest -I. test/cxx11_test.rb

package_set's Issues

Dependencies to Ruby Gems: Installation Order

Hi,

In my installation I am using ruby2.0 and some of the gems that are required depend (thin, sprockets and grape) on other gem (rack) which latest version does not support ruby2.0.

If I install the rack version 1.6.5 and then the other gems the installation goes well.

I tried to fix with these changes in rock.osdeps-ruby20 in two ways:

rack:
    gem:
        - rack<1.6.5

thin:
    gem: 
        - rack<1.6.5
        - thin
sprockets:
    gem: 
        - rack<1.6.5
        - sprockets
grape:
    gem: 
        - rack<1.6.5
        - grape

But still autoproj tries to install rack latest gem instead of the version that is supported.

How should this be solved?

No automatic installation of castxml on Ubuntu 16.04

castxml is not automatically installed on ubuntu 16.04.
Therefore orogen packages fail as autoproj tries to
build them using (the also not installed) gccxml.

tools/class_loader missing dependency

Hi,

class loader is build in debug mode, at least for Ubuntu 14.10 the libpocofoundation9-dbg osdep package is missing, which installs /usr/lib/debug/usr/lib/libPocoFoundationd.so.9.

There are two options to resolve this:

• add the osdep
• build as release

Also see my comment on:
#24

Where to put vizkit3d_debug_drawings

I am in the process of publishing the vizkit3d_debug_drawings library and would like to add it the rock-core package_set.

It depends on the following packages:

• gui/vizkit3d (rock-core package_set)
• gui/rock_widget_collection (rock-core package_set)
• gui/osgviz (rock-core package_set)
• base/boost_serialization (envire package_set)
• tools/orocos_cpp (rock-cpp package_set)

For this to work base/boost_serialization and tools/orocos_cpp would have to be moved to rock-core as well.

What do you think @doudou ?

bootstrap is broken

Continuous Integration for Rock Core

This issue intends to open the discussion on how to properly set up continuous integration for packages in Rock:

Existing examples in Rock:

• https://github.com/rock-core/rock-osdeps-package_set/blob/master/Dockerfile
• https://github.com/rock-core/autoproj/blob/master/.travis.yml
• https://github.com/rock-core/tools-pocolog2msgpack

qt4 deb packages for jammy

Hello Sylvain @doudou !
do you plan to create qt4 deb packages for jammy like it was done for focal (http://ppa.launchpad.net/rock-core/qt4/ubuntu/pool/main/q/)?

Checking out base/templates/doc Error

In remotes/rock.core/source.yml:70 the dependency base/templates/doc fails when fetching.

The dependency is also in remotes/rock.core/04stable.autobuild:69.

I don't know what new dependency should be provided. Is anyone working on this?

adding bundles to ROCK_BUNDLE_PATH breaks the system

See #16 for details

[Tutorial] Publishing the bundle

At Basics tutorial the publishing one [https://www.rock-robotics.org/rock-and-syskit/basics/publishing.html] , it was not clear where I should create the manifest.xml file.

the 'master' flavor can be selected while we are on a release

This is unsupported. Either rock-release or the package set code should warn and/or switch automatically to stable.

Don't exlude tools/apaka by default

tools/apaka is removed from the build configuration by default in 00new_packages.autobuild. Currently I am working on an automated way to produce various builds with apaka. Thus it is necessary to manually patch every buildconf manifest to contain - tools/apaka, otherwise the apaka binaries are not made available via env.sh. As every buildconf repo uses a different indentation, this process is unnecessarily complicated.

Change rock.osdep of vtk-qt4 for ubuntu 16.04

Due to this change in rock-core-rock: rock-core/rock-package_set@5f02bb9
the os-dependency vtk-qt4 should be changed to libvtk6-qt4-dev for ubuntu 16.04+.

Unsolicited stable to master override

There are other packages outside rock that also use stable and master branches, and if the are defined in the source.yml to use the stable branch. They are meant to use stable. This thing here overrides this:

package_set/overrides.rb

Line 2 in e4df64e

switched_packages = Rock.flavors.reset_invalid_branches_to('master')

This should only be a warning.

cxx11.rb incompatible with autoproj v1

cxx11.rb: Autoproj::OSPackageResolver is only known to autoproj v2, and effectively preventing the continued use of autoproj v1 installations without upgrading

tools/class_loader tries to build with catkin if the ros bridge is enabled

`tools/class_loader` produces broken `class_loader.pc`

When I build tools/class_loader, the installed class_loader.pc seems to be broken.

Probably this is a cmake issue. It seems to configure the dependencies as a semicolon-separated string, instead of space-separated string. On Ubuntu 20.04 it additionally writes the cmake target aliases instead of the actual libraries.

Output on Ubuntu 18.04:

prefix=/path/to/ws/install/tools/class_loader
exec_prefix=/path/to/ws/install/tools/class_loader
libdir=${prefix}/lib
includedir=${prefix}/include

Name: class_loader
Description: "Package for loading plugins at runtime"
Version: 
Requires: console_bridge 
Libs: -L${libdir} -lclass_loader /usr/lib/x86_64-linux-gnu/libboost_thread.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_atomic.so;/usr/lib/x86_64-linux-gnu/libpthread.so;/path/to/ws/install/base/logging/lib/libbase-logging.so;/usr/lib/libPocoFoundation.so;dl
Cflags: -I${includedir} 

Output on Ubuntu 20.04:

prefix=/path/to/ws/install/tools/class_loader
exec_prefix=/path/to/ws/install/tools/class_loader
libdir=${prefix}/lib
includedir=${prefix}/include

Name: class_loader
Description: "Package for loading plugins at runtime"
Version: 
Requires: console_bridge 
Libs: -L${libdir} -lclass_loader Boost::thread;Boost::system;/path/to/ws/install/base/console_bridge/lib/libconsole_bridge.so;/path/to/ws/install/base/logging/lib/libbase-logging.so;/usr/lib/x86_64-linux-gnu/libPocoFoundation.so;dl
Cflags: -I${includedir} 

Expected output (or similar):

prefix=/path/to/ws/install/tools/class_loader
exec_prefix=/path/to/ws/install/tools/class_loader
libdir=${prefix}/lib
includedir=${prefix}/include

Name: class_loader
Description: "Package for loading plugins at runtime"
Version: 
Requires: console_bridge 
Libs: -L${libdir} -lclass_loader /usr/lib/x86_64-linux-gnu/libboost_thread.so /usr/lib/x86_64-linux-gnu/libboost_system.so /usr/lib/x86_64-linux-gnu/libboost_chrono.so /usr/lib/x86_64-linux-gnu/libboost_date_time.so /usr/lib/x86_64-linux-gnu/libboost_atomic.so /usr/lib/x86_64-linux-gnu/libpthread.so /path/to/ws/install/base/console_bridge/lib/libconsole_bridge.so /path/to/ws/install/base/logging/lib/libbase-logging.so /usr/lib/x86_64-linux-gnu/libPocoFoundation.so dl
Cflags: -I${includedir}

For comparison, the version installed by my ROS distribution:

prefix=/opt/ros/melodic

Name: class_loader
Description: Description of class_loader
Version: 0.4.1
Cflags: -I${prefix}/include -I/usr/include
Libs: -L${prefix}/lib -lclass_loader /usr/lib/x86_64-linux-gnu/libboost_thread.so /usr/lib/x86_64-linux-gnu/libboost_system.so /usr/lib/x86_64-linux-gnu/libboost_chrono.so /usr/lib/x86_64-linux-gnu/libboost_date_time.so /usr/lib/x86_64-linux-gnu/libboost_atomic.so /usr/lib/x86_64-linux-gnu/libpthread.so /usr/lib/libPocoFoundation.so -ldl /usr/lib/x86_64-linux-gnu/libconsole_bridge.so.0.4
Requires: 

Move osqQt fork from rock.simulation to rock.core for Ubuntu 20.04

Hey,
I'm currently testing a basic rock core stack on my Ubuntu 20.04 machine with the provided QT4 backports. One thing I came across is that openscenegraph-osgQt was removed from openscenegraph and regrouped to an own repository. This is solved within the rock.simulation package set, but should be provided in the rock.core package set, as it includes vizkit3d (which needs osgQt).