-
Notifications
You must be signed in to change notification settings - Fork 20
Yujin Init
- Overview
- Installation
- [Quick Start](#Quick Start)
- Workspace Initialisation
- Build Cases
- Single Build
- Parallel Builds
- Cross Compiling
- Underlays
- Conveniences
These tools are wrappers around wstool
and catkin_xxx
to help setup builds. I did this because ros currently doesn't have anything yet to help much in three different cases:
- Multiple underlays
- Handling the increasing number of cmake variables (use cmake caches!)
- Cross compiling
Multiple underlays are at best an inconvenience with catkin_make (have to source multiple setup.bash's along the way to setting up) and at worst, limited in the sense that it is complicated to contrive nonlinear underlay patterns (e.g. consider two independent underlays).
> sudo pip install -U yujin_tools
# Make sure you have the latest ros build environment tools
> sudo apt-get install python-rospkg python-catkin-pkg python-wstool ros-groovy-catkin
Using the tools is a three step process, 1) init workspace, 2) init build, 3) make
A quick example of the usual steps for a source workspace on your pc:
> yujin_init_workspace ~/ecl_lite https://raw.github.com/stonier/ecl_core/groovy-devel/ecl_lite.rosinstall
> cd ~/ecl_lite
> yujin_init_build .
> yujin_make --install-rosdeps
> yujin_make
> yujin_make --install
Regular wstool style initialisation with url's:
> yujin_init_workspace ~/ecl_lite https://raw.github.com/stonier/ecl_core/groovy-devel/ecl_lite.rosinstall
You can also merge rosinstalls into an existing workspace. This can be down from the root (the directory below the src directory), or from anywhere if you've already sourced an already built yujin_make environment. Examples:
# directly
> yujin_init_workspace -j5 --merge foo.rosinstall
# from uri
> yujin_init_workspace -j5 --merge https://raw.githubusercontent.com/robotics-in-concert/rocon/indigo/rocon.rosinstall
# from rosinstall database
> yujin_init_workspace -j5 --merge ecl
You can also set the yujin tools (yujin_init_workspace
et. al) to use a different track (rosdistro) from the default:
# what is the current default?
> yujin_tools_settings --get-default-track
indigo
# set a different track default
> yujin_tools_settings --set-default-track hydro
You can even point it to your own custom rosinstall database (by default it uses yujin's database).
# where is the current rosinstall database?
> yujin_tools_settings --get-rosinstall-database-uri
https://raw.github.com/yujinrobot/yujin_tools/master/rosinstalls
# point at your own
> yujin_tools_settings --set-rosinstall-database-uri https://raw.github.com/foo/rosinstall_database/master
# Finally retrieve from your rosinstall database
> yujin_init_workspace ~/my_foo my_foo
The database itself just consists of yaml indexes for each rosdistro track. See yujin's database for an example.
Using a fairly standard concept here, that is the creation of build directories to house a build configuration - e.g. debug, release, arm cross-compiles or native builds. For the following, we assume an ecl_lite
workspace initialisation as above:
The default ros style for 99% of people.
> yujin_init_workspace ~/ecl_lite ecl_lite
> cd ~/ecl_lite
> yujin_init_build .
# Edit your config.cmake
> yujin_make --install-rosdeps
> yujin_make
> yujin_make --tests
> yujin_make --run_tests
> yujin_make --install
> yujin_make --pre-clean
Note that you don't have to reset the configuration when pre-cleaning. It reuses the cache in config.cmake
.
> yujin_init_workspace ~/ecl_lite ecl_lite
> cd ~/ecl_lite
> yujin_init_build native
> cd native; yujin_make --install-rosdeps; yujin_make
Toolchains and platform flags are selectable from a list (stored in the python module) or directories in ~/.yujin_tools/toolchains
, ~/.yujin_tools/platforms
. Here we truly make use of the parallel builds without alot of awkward sourcing as we jump from one build to another!
First off, let's download some cross compilers - cmake toolchain and platform modules are of no use unless you actually download those toolchains!
> sudo apt-get install g++-arm-linux-gnueabi g++-arm-linux-gnueabihf
Now the fun begins:
# Native build
> yujin_init_workspace ~/ecl_lite ecl_lite
> cd ~/ecl_lite
> yujin_init_build native
> cd native; yujin_make
# List the available cmake toolchain and platform modules
> yujin_init_build --list-toolchains
> yujin_init_build --list-platforms
> cd ~/ecl_lite
> yujin_init_build --toolchain=ubuntu/arm-linux-gnueabi --platform=arm/arm1176jzf-s arm
> cd arm; yujin_make
Note that you have to know which platform can be used by which toolchain. For example, the arm1176jzf-s settings we used above, don't work for the armhf compiler.
If you want to modularise your workspaces you can set up underlays to the current workspace (note we don't do any setup.bash
sourcing here, all the information necessary comes from the underlay list). Example below assumes I've got the usual rosinstalls floating around in ~, but url's could also be used.
> yujin_init_workspace ~/ecl ecl
> yujin_init_workspace ~/kobuki kobuki
> cd ~/ecl
> yujin_init_build .; yujin_make
> cd ~/kobuki
> yujin_init_build --underlays="~/ecl/devel" .; yujin_make
> yujin_make
When no catkin can be found in your sources or your underlays, then it will automatically try and add the underlay specified by the currently set default track (yujin_tools_settings
), e.g. /opt/ros/groovy
for track groovy
.
You can also underlay to the individual or even a shared install space rather than the devel spaces.
> yujin_init_workspace ~/ecl ecl
> yujin_init_workspace ~/kobuki kobuki
> cd ~/ecl
> yujin_init_build --install=/opt/yujin/groovy .
> yujin_make --install
> cd ~/kobuki
> yujin_init_build --install=/opt/yujin/groovy --underlays="/opt/yujin/groovy;/opt/ros/groovy" .
> yujin_make --install
# Further workspaces can also use the shared /opt/yujin/groovy underlay as well.
Note the underlays should be directed so that priority is given to the first in the list.
The yujin init build function also sets up our usual gnome-terminal
, konsole
and eclipse
launch scripts. These source the devel workspace's setup.bash
if it is ready. Use them as launchers.