目次
- 目次
- はじめに
- catkinとは
- ビルドシステムとは何か?
- なぜROSは独自のビルドシステムを使用しているのか？
- なぜcatkinを作ったのか？rosbuildを不採用にした理由
- ビルド結果のインストールとシームレスなリリース
- ワークスペース環境のオーバレイの簡素化
- ビルドフラグの明確なエクスポート
- File System Hierarch (FHS)の準拠
- メタパッケージとスタックの廃止
- rosbuildからcatkinへの移行について
- スタックとの別れとメタパッケージとの出会い
- rosbuildとcatkinのビルドステップの違い
- 依存ファイル管理
- CMakeLists.txt
- タグの詳細
- setup.py
- rosbuildのパッケージをcatkinに移行する方法
- catkinで新しいパッケージを作る方法
- 参考資料
- MyEnigma Supporters
はじめに
ロボット用OSであるROSは2013年の1月にリリースされた
Groovyから新しいビルドシステムcatkinを採用しています。
この記事では文末の参考記事を元に、
catkinについてまとめたものです。
catkinとは
catkinとは、ROSにおける新しいビルドシステムの
マクロとインフラのことです。
ROSにおける公式なビルドシステムであり、
以前のROSのビルドシステムであるrosbuildの後継となります。
catkinはCMakeのマクロとPythonのスクリプトを組み合わせて、
CMakeの一般的な上位のワークフローの機能を有します。
また、catkinはrosbuildよりもより使いやすいように出来ており、
パッケージ配布をしやすくし、
クロスコンパイルをサポートし、
そして、ソフトの移植性が向上しています。
catkinの使い方は基本的にはCMakeに似ていますが、
パッケージ検索機能や、
複数の独立したプロジェクトを同時にビルドする機能なのが追加されています。
catkinという名前は、catkinが作られたWillow Garage社の名前の由来である
ヤナギの木になる動物のしっぽのような花の名前から来ています。
(冒頭の写真はヤナギ(Willow)の木になるcatkinです.）
ビルドシステムとは何か?
ビルドシステムとは、ソースコードから、
エンドユーザが使用できる“目的物”を生成するものです。
この目的物は、ライブラリと形をしていたり、
実行コードであったり、スクリプトであったり、
C++のヘッダーファイルなどのインターフェースであったり、
動的コードであったりなど、様々な形をしています。
ROSの専門用語としては、
ソースコードは”パッケージ”の中に置かれ、
それぞれのパッケージはビルドされた時に、
ひとつ以上の目的物となります。
有名なビルドとしては、
広くソフトウェア開発に使用されている
Make - GNU Project - Free Software Foundation http://www.gnu.org/software/make/
Autoconf - GNU Project - Free Software Foundation (FSF) http://www.gnu.org/software/autoconf/
CMake - Cross Platform Make http://www.cmake.org/
Apache Ant - Welcome http://ant.apache.org/ (主にJavaに使用される)
などがあります。
加えて、
Qt CreatorやMicrosoft Visual Studio, Eclipse
などの統合開発環境(IDEs)もビルドシステムの一つです。
これらは、それぞれがサポートしている言語に対する
独自のビルドシステムを有しています。
一般的に、これらのIDEsのビルドシステムは、
AutoconfやCMakeを使用しているだけの場合も多いです。
ビルドするために、ビルドシステムは
多くの情報を管理する必要があります。
例えば、
ツールチェーンのコンポーネント(C++ コンパイラなど)
ソースコードの位置、コードの依存関係
外部コードの場所やその依存関係
どのビルド目標がビルドされるべきで、
どこにビルドするのか
そしてそれらはどこにインストールされるのか、などです。
一般的にこのような情報は、
いくつかの設定ファイルによって管理されます。
IDEでは、ワークスペース・プロジェクトのメタ情報
(例：Visual C++のプロジェクトファイル)として、
保存されています。
CMakeでは”CmakeLists.txt”として、
GNU Makeでは”Makefile”として保存されています。
ビルドシステムが適切な順番でビルドするためには、
この情報を使用してソースコードをビルドする必要があります。
ROSではcatkinという独自のビルドシステムを使用しています。
これはCMakeを拡張してものであり、
パッケージ間の依存関係を管理できるようにしたものです。
なぜROSは独自のビルドシステムを使用しているのか？
ある一種類のソフトウェアプロジェクト開発であれば、
AutoconfやCMake、IDEなどの既存のツールで十分でしょう。
しかし、これらのツールは巨大で、複雑で、複数種類のシステムに跨る
ソフトウェア開発に使用するのは難しいという問題があります。
これは非常に多くの依存関係や、複雑なコードシステム、
特定のビルド対象に対する独自のビルドルールなどの問題を
解決するのが難しいからです。
また、これらのツールをソフトウェア開発者によって、
デザインされ、汎用的に使われるように設計されたため、
ソフトウェア開発の経験がないと、
使用するのが難しいという問題がありました。
ROSは、ゆるい繋がりを持った、
非常に多くのパッケージから構成されます。
つまり、ROSでは独立したパッケージが
お互いに依存しており、
それらは様々なプログラミング言語や、
様々なツール、コーディング規約を使用していることになります。
これにより、それぞれのパッケージにおけるビルドは、
全く異なるプロセスになるのです。
rosbuildとcatkinでは、
多くの関連するパッケージ同士を開発する時の
利便性を改良しています。
つまり、rosbuildとcatkinは、
ROSコードのビルドと実行のプロセスを簡略化するために、
様々なツールや方式を使用しているのです。
もし、これらのツールが無ければ、
ROSベースのコードを効率的に共有することは難しいでしょう。
なぜcatkinを作ったのか？rosbuildを不採用にした理由
ROSが始まった当初から、
ROSのビルドシステムとしてrosbuildが提供されてきました。
しかし、ROSの急激な発展と、数年に及ぶ経験から、
rosbuildのいくつかの問題点が発覚してきました。
catkinはこれらの問題を解決するように、開発されています。
ROSの開発の初期の段階において、rosbuildは開発されたため、
ROS communityの数年に及ぶ要求をサポートするために進化して行かなければなりませんでした。
しかし、これにより、最適ではない決定が下されたり、
改変されたり、不必要な複雑性を有することになりました。
新しくできた開発団体であるOSRFにおいて、
これらの問題を解決するために、
新しいビルドシステムを作るべきだという意見が出始めました。
Pythonから純粋なCMakeへの移植性
rosbuildにおける一番の問題の一つは、
Microsoft Windowsなどの
様々なOSに対する移植性が難しいことでした。
なぜなら、rosbuildはビルドするために、
BashのスクリプトやGNU Make, CMakeなどを
組み合わせて使用しているからです。
rosbuildでは、ビルドシステムを呼ぶために、
rosmakeなどのrosbuildの独自のスクリプトを呼ぶ必要がありました。
rosmakeはBashスクリプトであり、
これはCMakeを呼び、別のmakefileを作成し、
最後に再びmakeを呼ぶものでした。
catkinはこの部分において、より簡便化されており、
単純にCMakeを呼ぶだけのものになっています。
catkinはCMakeのマクロと幾つかのPythonコードで実装されています。
CMakeとPythonの移植性が高いため、
catkinはPythonとCMakeがサポートしているすべてのシステムにおいて、
簡単に移植することができます。
実際、catkinのプロジェクトは、他のCMakeのプロジェクトにおいて、
シームレスに使用することができます。
例えば、ビルドされたcatkin projectはエクスポート情報を生成しますが、
これをCMakeのfind_package()関数で検索することもできます。
ROSからの切り離し
ROSにおける一つの哲学として、
ソフトを構築・管理・利用するためのツールを
できるだけROS専用にしないということがあります。
またできるだけ、
より性能がよく、広く使われており、第三者が開発している
オープンソースのツールをできるだけ使うようにしてきました。
(例えば、独自のXMLパーサーを使用せずに、
libtinyxmlを使用していることなどです)
catkinはROSのソフトウェアシステムから独立しているため、
ROSでは無いプロジェクトにおいても、使用することができます。
これにより、catkinでは、
catkinを使用してないプロジェクトとcatkinプロジェクトを
簡単に混ぜて使用できるのです。
catkinでは、純正のCMakeに沢山の機能を追加しているため、
ROSに関係ないプロジェクトにおいても、
非常に有能な開発ツールとして使用できます。
Out-of-Source ビルド
rosbuildではあるパッケージをビルドする際に、
ビルド結果と、すべての中間ファイル(オブジェクトファイルなど)を
コードがあるフォルダ内に生成します。
これは一般的に”in-souse ビルド”と呼ばれており、
元々無かったファイルが作成されることよって、
ソースツリーを破壊してしまう可能性が指摘されていました。
catkinでは、ビルド結果をそのパッケージの外のフォルダなど、
任意のフォルダにビルドすることができます。
このようにビルド結果をソースコードフォルダの外に作成できる方法を
Out-of-Source ビルドといい、catkinではこの方法を取り入れました。
ビルド結果のインストールとシームレスなリリース
CMakeを使用しているcatkinの重要な利点の一つとしては、
インストールするビルド結果を指定できることです。
catkinでは、あるコードがビルドされて、ビルド結果が生成された後、
ユーザが指定したフォルダに置かれます
この時点では、使用できるビルド結果があったとしても、
システムにはインストールされたことにはなりません。
インストールとは、ビルド結果を
システムフォルダなどにコピーし、
ユーザが利用できるようにすることを指します。
例えば、GNU Makeを使ってビルドを行った場合、
makeコマンドとmake installコマンドには違いがあります。
makeはコードをビルドするだけですが、
make installは、ビルドの後にビルド結果をインストールフォルダにコピーするのです。
rosbuildは、ビルド結果をインストールする機能はありませんでした。
あるROSのバーションをリリースした時、
ROSの開発チームは、すべてのパッケージをビルドし直して、
ビルド結果とビルド結果をインストールできるパッケージ(.debファイル)
を抽出する、それぞれの対象OSに対して独自のスクリプトを使用する必要があったのです。
しかし、catkinでは、
単純に”make install”とタイプすれば、
すべてのビルド結果がインストールされます。
これにより、ユーザがROSを使用するのを簡単にするだけでなく、
ROS開発チームがROSの新しいバージョンをよりスムーズにリリースすることができるのです。
加えてcatkinでは、どのビルド結果がインストール可能で、
どのビルド結果がインストール不可能なのかを指定することができます。
あるパッケージにおいて、すべてのビルド結果が使用可能であるわけではない場合や、
すべてのビルドがエクスポートを意図したものではないのです。
例えば、ユニットテストそのものをインストールすることは意図されていませんが、
ユニットテストに使用しているライブラリや付属コンポーネントは使用できる時などはあります。
rosbuildでは、このようなインストールの可・不可を指定できなかったため、
無駄なビルド結果がパッケージ内で膨れ上がってしまうという問題がありました。
ワークスペース環境のオーバレイの簡素化
オーバレイの考え方は、ROSの開発初期段階にも存在しました。
それぞれのオーバレイは、ある特定のセットアップファイル( setup.bash, setup.py, setup.sh)
によって設定され、このファイルが読み込まれると適切な環境が出来上がります。
catkinでもこれらの環境セットアップファイルを使用するコンセプトを維持しています。
しかし、rosbuildと比べて細かい違いも存在します。
catkinのセットファイルを読み込んだ時、
これまでの既存の環境変数を拡張するのではなく、上書きするようになります。
このように聞くと、ツールチェーンはどのように機能するのかというのが疑問に思えるかもしれません。
簡単に言うと、catkinは多くのセットアップファイルを異なった状態に応じて生成し、
複数の環境におけるツールチェーンは一つのセットアップファイルによって統合されるように機能します。
もし、あなたがワークスペース内でコードをビルドした場合、
セットアップファイルは”devel space”内に生成されます。
もし、それらのセットアップを読み込んだ場合、
ビルドした時に使用されていた他のワークスペースのセットアップファイルは、
自動的に読み込まれるのです。
例えば、もし貴方が貴方のワークスペースをビルドするために、
を読み込んだとします。
するとdevel spaceにあるビルドの際に使用したsetup.bashの内容は自動的に
/opt/ros/groovy/setup.bash
の中に追加されるのです。
同様に、もし貴方があるワークスペースを読み込んだ場合、
そのワークスペースはsetup.bashファイルに追加され、
すべてのワークスペースにオーバレイされ、ビルドの際に使用できるようになります。
ビルドフラグの明確なエクスポート
rosbuildでは、インクルードパスやライブラリ、ライブラリパスなどの
パッケージのリソースやリソースパスは明確に定義されていませんでした。
その代わり、追加のコンパイラ・リンカフラグを
manifest.xmlファイルの中にハードコードしており、
自動的にそのファイルで指定された依存関係は
ビルドシステムによって追加されるようになっていました。
catkinからの変更点は非常に小さいものです。
rosbuildでは、rosbuild自身が依存関係を管理していますが、
これはROSレベルでの管理でした。
しかしcatkinでは、依存関係を明確な情報ファイルとしてエクスポートし、
CMakeレベルで管理するようにしました。
File System Hierarch (FHS)の準拠
catkinを使ったビルド結果は、File System Hierarch (FHS)に準拠しています。
これは、Unixに似たファイル管理システムとして一般的なディレクトリ構造です。
これにより、ROSはより多くのオープンソースシステムとの親和性が向上しています。
FHSへの準拠に関するより詳しい情報は下記のリンク先を参照して下さい。
REP 122 -- Filesystem Hierarchy Standard layout changes for ROS (ROS.org) http://www.ros.org/reps/rep-0122.html
メタパッケージとスタックの廃止
ROS Groovyから、ROSではパッケージとスタック(複数のパッケージを一つにまとめたもの)
の区別は無くなりました。
rosbuildでは、それぞれのパッケージはCMakeLists.txtファイルとmanifest.xmlファイルを持ち、
それぞれのスタックはstack.xmlファイルを持っていました。
そして、それぞれのスタックはDebianパッケージとしてパッケージ化されていました。
catkinでは、CMakeList.txtとmanifest.xmlに似たpackage.xmlというファイルのみを持ち、
パッケージはパッケージとしてのみ存在します。
しかし、新しいコンセプトと導入されたメタパッケージを使用すれば、
スタックのコンセプトと似た管理をすることができます。
メタパッケージは他のパッケージに依存した特別なパッケージの一種です。
メタパッケージフォルダは特にそのパッケージが依存関係を持っていない場合は、
他のファイルやフォルダを含むべきではありません。
なぜなら、ファイルシステムにおいて、パッケージはネストできないからです。
rosbuildからcatkinへの移行について
catkinのワークフローはrosbuildの方法と似ていますが、
幾つかの部分で異なっています。
慣れないうちは、新しいビルドシステムを勉強しなくてはならないことに
苛立つかもしれませんが、少し勉強すれば、catkinを使用してビルドしたり、
実行したり、テストをすることは非常に簡単であることに気がつくでしょう。
catkinの専門用語: DryとWet パッケージ
rosbuildからcatkinへの移行期間中は、
rosbuildを使用しているパッケージをDryパッケージ
catkinにアップデートしたパッケージをWet パッケージと呼ぶことにします。
catkinとrosbuildの互換性について
rosbuildはROSと分離できないほど固く結びついていますが、catkinは違います。
従って、すべてのDryパッケージをWetパッケージに変更することは並大抵のことではありません。
これにより、ROSのGroovyにおいても、rosbuildは残りますし、catkinと共存することになります。
しかし、今後徐々にcatkinに移行していくでしょう。
すべてのコアソフトと有名なパッケージに関しては、Groovyでcatkinに移行しつつあります。
しかし、まだ多くのパッケージはrosbuildを使っていますし、今後も共存はできます。
catkinとrosbuildの間の上位互換性を保持する努力は今後も継続されます。
スタックとの別れとメタパッケージとの出会い
スタックのコンセプトはROSから削除されました。
一方、パッケージのコンセプトは残っています。
なぜスタックのコンセプトが削除されたかと言うと、
スタックは不必要なソフトの集合レベルであり、
ROSの内部実装の面でも、ユーザに対しても、
より混乱させるものであると判断されたからです。
しかし、スタックの機能はメタパッケージという形で利用することができます。
これはpackage.xmlの中にメタパッケージタグを持つようにする方法です。
詳しくは、こちらの資料を参考にしてください。
catkin/package.xml - ROS Wiki http://wiki.ros.org/catkin/package.xml
rosbuildとcatkinにおける環境構築ファイルと環境変数の違い
rosbuildとcatkinの両方とも、環境変数に依存しています。
これらの環境変数は環境設定ファイルであるsetup.*ファイルを通して設定されます。
設定ファイルの拡張子はユーザが使用しているシェルの種類に対して変わります.(bash, zsh,sh)
しかし、rosbuildを使用したパッケージをビルドする時以外は、
rosbuildで使用した環境変数はcatkinではあまり重要ではありません。
rosbuildでは最も重要な環境変数はROS_PACKAGE_PATHであり、
ビルドする時と実行するときに使用する、パッケージへのすべてのパスのリストが含まれています。
この環境変数が設定されていない場合、
rosmakeやrosrunはリソースを見つけることができません。
Dryパッケージに設定ファイルが読み込まれると、
ROS_PACKAGE_PATHにパスの情報が追加されるのです。
catkinでは、最も重要な環境変数はCMAKE_PREFIX_PATHです。
これは、CMakeが他のCMakeプロジェクトを探す助けをします。
catkinのパッケージはCMakeプロジェクトの特別なケースの一つであるため、
この環境変数が必要になるのです。
catkinの設定ファイルが読み込まれると、
CMAKE_PREFIX_PATHに関連するパッケージのパスが追加されます。
つまり、CMAKE_PREFIX_PATHとROS_PACKAGE_PATHは
本質的に同じ役割をしているのです。
rosbuildとcatkinのビルドステップの違い
rosbuildではパッケージはrosmakeという特別なスクリプトによってビルドされていました。
catkinではcmakeコマンドを使用した後に、makeコマンドを使用することにより、
ワークスペースのすべてのパッケージをビルドすることができます。
cd ~/catkin_ws/build
cmake ../src
make
またrosbuildでは、個々のパッケージをビルドするには、
rosmakeの後にパッケージ名を続けてビルドを実行しました。
rosmake rviz
catkinでは,makeファイルがCMakeから生成されることにより、
それぞれのパッケージをビルドすることができます。
(一つのパッケージが複数のビルド結果を出力することもあります.)
例えば、rvizがあなたワークスペースにある場合、
あなたは下記のようなコマンドでrvizをビルドすることができます。
cd ~/catkin_ws/build
cmake ../src
make rviz
タブ補完もサポートされており、
makeの後にタブキーを押すと、ビルド可能な対象の名前を補完することができます。
rosbuildとcatkinにおけるビルド結果のパスの違い
rosbuildでは、ビルド結果はパッケージフォルダの中に作成されます。
これは、rosmakeやrosrunを使用している多くのROSユーザにとっては問題はありません。
なぜなら、これらのツールは環境設定ファイルから、様々な設定が明確だからです。
catkinでは、develディレクトリにビルド結果が生成され、
インストールディレクトリにインストールすることも可能です。
しかし、catkinにおいても、rosbuildのプロジェクトと同様に、
環境設定ファイルから設定を読み込めるため、
特にrosbuildとは大きな変更はありません。
ランタイムにおけるrosbuildとcatkinの違い
rosbuildとcatkinの両方において、
ROSアプリケーションは、直接起動するのではく、
rosrunやroslaunchを使用して起動するべきです。
rosrunやroslaunchは、環境変数によって、
実行ファイルやランタイムライブラリを検索することができます。
内部的にはrosrunはrosbuildとcatkinの両方に対応するために、いくつかの作業を行っていますが、
rosrunに関しては、ユーザはcatkinとrosbuildの区別をする必要はないようになっています。
依存ファイル管理
catkinの現在のバージョンでは、ファイルの依存関係を複数の場所に記述する必要があります。
下記はexample_pkgという２つの依存関係を持つパッケージのpackage.xmlファイルです。
catkinのパッケージであるcpp_commonと
システムライブラリであるlog4cxxに依存しています。
package.xml
…
example_pkg
catkin
cpp_common
log4cxx
gtest
…
cpp_common
log4cxx
package.xmlの書き方のルールに関しては、下記のREP127を参照して下さい。
REP 127 -- Specification of package manifest format (ROS.org) http://www.ros.org/reps/rep-0127.html
また、いくつかの詳しい説明に関しては、下記を参照して下さい。
catkin/package.xml - ROS Wiki http://wiki.ros.org/catkin/package.xml
package.xmlは下記の事柄の役目を担っています。
1. catkinパッケージに対するconfigureステップ(cmake)の順番指定
2. リリースツールであるbloomのために、依存関係を決定する
bloom - ROS Wiki http://wiki.ros.org/bloom
3. catkinではないパッケージにおいて、rosdepのための依存関係の設定する。
4. roswiki/graph toolのために、ビルドやインストール、実行時の依存関係のドキュメント
rqt_graph - ROS Wiki http://wiki.ros.org/rqt_graph
タグの詳細
依存ファイルを規定し、もし依存ファイルが同じワークスペースに存在している場合は、
まず初めに環境設定されます。
もし、ワークスペースに存在していない場合は、
その依存ファイルの環境設定ステップは無視されます。
例えば、先ほどの例では、roscpp_commonとlog4cxxは
環境変数設定ステップでは無視されます。
なぜならこれらはcatkinパッケージではないからです。
クロスコンパイルをする際に、
目的のアーキテクチャではなく、
現在のアーキテクチャで使用することを意味します。
もし、クロスコンパイルで使用しないのであれば、
Catkinパッケージでは、run-testというプレフィックスを使用して
makeの対象を設定するマクロを使用しています。
これらのマクロは
catkin_make run_tests[_...]
で呼び出したり、単純に
run_tests[_…]
で呼び出すことができます。
これにより、ビルドする前にシステム依存ファイルを簡単にインストールすることができます。
一つ目は、パッケージ内において実行すべき対象を明示する機能です。
しかし、このためにはサードパーティのパッケージが必要な
すべての依存ファイルを明示する必要があります。
(例えば、あなたのパッケージBががパッケージAに依存していて
別のパッケージCがパッケージBに依存している場合です)
これは、実行時におけるライブラリや
サードパーティのビルド時のヘッダーに生じる問題です。
従って、
またdebianのパッケージを作っている時には、すべての
apt-getによってインストールされている必要があります。
また現状では、しばしば
同じものになることがあります。
しかし、将来的には下記のようになることを計画しています。
cpp_common-dev
cpp_common
これにより、依存ファイルは分割されるようになります。
CMakeLists.txt
下記はCMakeLists.txtの例です。
find_package(catkin REQUIRED COMPONENTS cpp_common geometry_msgs)
find_package(Log4cxx QUIET)
generate_messages(DEPENDENCIES geometry_msgs)
catkin_package( CATKIN_DEPENDS cpp_common
geometry_msgs DEPENDS Log4cxx)
add_library(example_lib src/example.cpp)
target_link_libraries(example_lib ${catkin_LIBRARIES} ${LOG4CXX_LIBRARIES})
add_dependencies(example_lib geometry_msgs_gencpp)
一般的に、CMakeLists.txtはビルドプロセスの準備と実行を担っています。
log4cxxを見ると分かる通り、システムライブラリの名前と、
パッケージを探すときに使用する名前は一緒ではありません。
これがpackage.xmlを読み込むのではなく、
もう一度依存関係を明示しなくてはいけない理由になります。
タグの詳細
下記のようにCMakeList.txtに記述することと、
find_package(catkin REQUIRED COMPONENTS cpp_common)
target_link_libraries(example_lib ${catkin_LIBRARIES} ${LOG4CXX_LIBRARIES})
下記のように記述することは同じです。
find_package(catkin REQUIRED)
find_package(cpp_common REQUIRED)
target_link_libraries(example_lib ${catkin_LIBRARIES} ${cpp_common_LIBRARIES} ${LOG4CXX_LIBRARIES})
この例ではexample_libという一つのライブラリを作成するだけです。
もし、より多くを作成したい場合は、${catkin_LIBRARIES}を使うのではなく、
個々のライブラリに対して、リストにした方が良いです。
依存関係に関しては、
generate_messages(DEPENDENCIES geometry_msgs)
catkinのマクロではない,message_generationマクロを使用してください。
下記の宣言については、
catkin_package(
CATKIN_DEPENDS cpp_common
DEPENDS Log4cxx
)
もし、サードパーティのパッケージがexample_pkgを使用したい場合は、
cpp_commonやlog4cxxのビルドフラグは自動的に使用されることに注意して下さい。
従って、package.xmlのrun_dependの依存ファイルのみが、
このタグでは必要になります。
下記の宣言に関しては、
add_dependencies(example_lib geometry_msgs_gencpp)
geometry_msgsのc++のメッセージヘッダはexample_libがビルドされる前にビルドされます。
もしくは、もしcatkinワークスペースで作業をしている場合には、
ヘッダーが無いというコンパイルエラーが出るでしょう。
(catkinワークスペースの外では、この行はなんの機能もしません)
setup.py
もしあるパッケージが他のパッケージを使用するために、
pythonモジュールを宣言した場合は、
それらのモジュールはsetup.pyで宣言される必要があります。
技術的には、これにより依存関係の宣言をしなくても良くなります。
from distutils.core import setup
setup(
…
requires=['rospy'],
)
ここで使用する名前は、catkinのパッケージの名前化、
pypiで使用されているパッケージの名前である必要があります。
pypiで使用されているパッケージ名は、しばしばapt-getで得られたパッケージと
名前が違う可能性があります。
(例： pypiではnoseだが、apt-getではpython-noseなど)
しかし、catkinでは現在の所、
このrequires変数の部分は気にしておらず、
rospyのようなパッケージはまだpypi経由では配布されていません。
従って、現在の所、この依存関係の部分はあまり重要ではありません。
もしあなたのcatkinパッケージがpypiにしか存在しない
パッケージに依存している場合、
このrequres変数の部分を使用して、
あなたのパッケージをpipでインストールできるようにする必要があります。
rosbuildのパッケージをcatkinに移行する方法
前述のように、groovy, hydroはcatkinだけでなく、
rosbuildも併用利用可能なので、
Fuerteで作ったrosbuildパッケージなどはそのまま使えます。
下記は移行方法のメモです。
最初に一回だけやること
1. sudo rosdep init
2. rosdep update
毎回やること
1. /catkin_ws/srcにパッケージを移動
2. パッケージに移動
3. make clean
3. rosmake
catkinで新しいパッケージを作る方法
1. パッケージを作成
catkin_create_pkg beginner_tutorials std_msgs rospy roscpp
2. srcディレクトリを作成し、ファイルを作成
例 src/talker.cppを作成
3. CMakeLists.txtを修正
add_executable(talker src/talker.cpp)
target_link_libraries(talker ${catkin_LIBRARIES})
4. catkin_make
5. rosrun beginner_tutorials talker
