catkin 與 rosbuild解析及兩者區別和聯繫 [官方文檔翻譯]
轉載自wiki.ros.org/cn/catkin_or_rosbuild
本頁面試圖總結闡明catkin與rosbuild的不同。本頁面的信息源自catkin文檔，catkin API reviews，以及catkin源代碼。
1. 開發catkin的動機
使用rosbuild將ROS程序安裝到其他系統或架構上是很麻煩的，這是rosbuild存在的主要問題，也是後來爲何要開發catkin的原因。
而爲了解決上面這個問題，提高可移植性的關鍵是爲ROS包提供安裝目標，並服從FHS的安裝佈局。如果僅改變rosbuild並不是說不可能實現，但這實現似乎很難。
所以，catkin主要的設計過程是爲CMake宏、變量和python寫幫助函數
catkin的設計者們也就此試圖改進catkin的使用體驗，以減少在程序構建時多依賴的項目對cmake和rosbuild的使用。 而解決這些問題的動機在於，rosbuild緩慢的構建速度是被人們抱怨最多的地方。
以下是catkin主要的設計實現目標：
- 將白名單的文件集作爲安裝目標安裝
- 兼容FHS文件佈局
- 自動生成符合cmake的配置文件
- 外源構建（也用於交叉編譯）
- 僅使用一個命令，就可以以正確的順序構建多個項目
- 編譯時允許使用標準cmake命令，而不是包裝器的命令
- 在開發週期無需安裝
- 加速編譯週期，使用並行編譯，對c ++文件跨相互依賴的項目編譯
- 拆分配置和構建階段，以提高構建速度
- 通過避免對資源進行多次類似rospack的查找，來提高構建速度（使用單個cmake查找）
2. 區別
2.1功能包與功能包集的概念
rosbuild定義了兩個關鍵概念，即堆棧和包。包Packages是一個包含manifest.xml和源文件的文件夾。堆棧Stack是一個包含stack.xml文件的文件夾。如果包Package是堆棧stack的子文件夾（包括源代碼中的安裝佈局），那麼該包是堆棧的一部分。堆棧只能依賴於其他堆棧，包也只能依賴於其他包。
在使用catkin的時候，功能包是構建和發佈的原子單位。功能包集非原子釋放單元，但可用於代替堆棧。使用catkin時，源中的功能包是具有名爲package.xml的清單文件和源文件的文件夾。但是，安裝後，由於FHS要求，功能包文件夾中不再嚴格包含功能包工件。
考慮到對更加輕便的ROS安裝的需求，設計者們將包作爲發佈的原子單元，因爲不期望的包package不用與堆棧stack一起安裝。以遵守FHS佈局，允許在各種操作系統和架構上更輕鬆地安裝ROS。
2.2構建過程
rosbuild中的構建過程由ROS_PACKAGE_PATH環境變量，rosmake命令和rospack庫三者驅動。
rosmake命令通過爬取ROS_PACKAGE_PATH中列出的目錄來找到包，然後遵守依賴關係的順序在找到的所有包文件夾上調用make命令進行編譯。 make命令通常依賴於cmake，並且都配置和構建項目源。 使用rospack庫查找依賴關係，rospack庫還使用ROS_PACKAGE_PATH來查找屬於這些包的文件。 對於每個功能包，cmake和make被分開調用，這也重複了爲幾個包找到依賴的工作量。
而在catkin命令中，構建的過程由工作空間文件夾，標準cmake命令和用於查找依賴關係的cmake約定驅動。
工作空間文件夾中包含一個cmake文件，它將僅爬取catkin軟件包的工作區文件夾，並配置這些文件夾的結構。在配置期間，cmake配置文件會自動生成。 依賴關係中的資源使用自動生成的cmake配置文件，而不是通過rospack來查找。這也允許第三方軟件構建在已安裝的ROS包上，而不需要使用任何ROS構建工具鏈。
對於純cmake語句來說，CMAKE_PREFIX_PATH環境變量包含了將被搜索的位置，替換了特定於ROS的ROS_PACKAGE_PATH變量。
構建過程（調用make）只編譯構建目標，潛在地允許了跨相互依賴項目（必須使用rosbuild順序構建）並行編譯文件。
因此，與rosbuild相比，catkin越來越多人使用的主要原因是：
- 配置一次，構建多次;僅在需要時重新配置
- 一次配置過程，使用cmake（只需要進行一次查找相同的依賴關係的操作）
- 跨越依賴項目編譯（即使跨越相互依賴的項目也並行編譯）
爲防止可能出現的命名空間衝突，該設計有一些注意事項，主要是cmake目標具有相同的名稱，其他全局（緩存）變量和多個不兼容的find_package調用。對此，解決方式是命名標準的對象和變量，孤立進行catkin構建（使用catkin_make_isolated）並拆分catkin工作區。
2.3打包
有工具鏈創建軟件包文件可安裝Ubuntu的rosbuild和catkin包。 rosbuild包與它們的源文件和編譯文件一起被安裝在單個文件夾中。一個堆棧中的所有包被打包到單個分發單元中，常常安裝用戶不想要的包。
catkin包安裝時通常沒有不需要運行代碼的源文件。也只有用戶想要安裝的軟件包（而不是像rosbuild一樣堆棧）。
按照FHS標準的要求，catkin包的安裝文件分佈在多個文件夾中。 ROS仍然區分全局和本地可執行文件夾。這意味着可執行文件通常不在PATH中的全局bin文件夾中，而在lib或共享的子文件夾中（取決於它們是二進制文件還是腳本），應該使用rosrun來調用。
遵循FHS的好處是，可以輕鬆地爲各種操作系統（Unix，BSD，其他linux發行版）和軟件包管理器打包這些軟件包，並且該軟件可以構建在軟件包之上，而不需要依賴於特殊的工具鏈。所以已被安裝的catkin包可以很容易地重複使用，而不需要catkin重新構建。
2.4工作空間WorkSpace佈局
rosbuild允許用戶將包開發到ROS_PACKAGE_PATH上的任何位置。 典型的用法將鼓勵單個源工作空間文件夾。 rosmake可以通過包的名稱（或使用當前文件夾的回退）在任何地方被調用，並且遞歸地構建給定包的依賴關係圖。 ROS_PACKAGE_PATH必須由用戶來管理，並鼓勵使用戶用rosinstall / rosws命令來生成合適的*.sh安裝文件，以及在許多項目中提供VCS操作。 每個項目文件夾也用作構建空間，因此每個軟件包只有一個構建空間。
使用catkin時，每個構建或配置過程被嚴格限制在單個工作區文件夾，該文件夾中必須包含由catkin提供的cmake文件用以指導配置過程。 構建和配置過程必須從特定文件夾啓動（或作爲選項傳遞），但不可能輕易地構建單個軟件包及其依賴關係中的所有目標。 由於catkin從源文件夾分離出了構建空間，因此可能會有多個構建空間。 Catkin還定義了一個開發空間和一個安裝空間。 這兩者都指的是生成了用於使用這些空間的.sh安裝文件的源文件夾。 這意味着由rosinstall和rosws命令所生成的安裝程序.sh不能再使用了。 wstool命令替換了rosinstall和rosws以僅執行VCS操作。
這些變化有利於需要多個構建空間的開發人員，例如用於交叉編譯等目的。與rosbuild或純cmake命令相比，這些更改還使得編譯週期的速度有一定的提高。
默認catkin工作流依賴於以單個文件夾作爲中心源文件夾，該中心源文件夾具有一個由catkin提供的CMakeLists.txt文件。這會調用一個函數，來爬取這個文件夾以供catkin包構建。這不同於rosbuild，而在rosbuild中，是使用ROS_PACKAGE_PATH確定要爲要構建的包進行爬取位置列表的。因此，通過ROS_PACAGE_PATH將位置列入rosbuild的白名單。相反，在catkin中，位置被列入黑名單（所有在src文件夾中找到的包均會被使用，除非他們有一個標記文件）。
疊加方式也是不同的，因爲rosbuild依靠rospack來從多個候選項中標識出具有相同名稱的單個包以用於構建。這是通過使用ROS_PACKAGE_PATH作爲第一優先級完成的，最早的查找作爲第二優先級在ROS_PACKAGE_PATH中搜索單個位置。 catkin不允許在同一位置（src文件夾）有多個包，但允許通過鏈接的工作空間進行覆蓋。然而，這種覆蓋是不合適的，因爲覆蓋語義對每個工作空間來說是局部的。
2.5工程文件
使用rosbuild時，每個包需要有一個manifest.xml文件和一個Makefile文件，並且通常還有一個由Makefile使用的CMakeLists.txt文件。開發人員在CMakelists.txt文件中聲明瞭某些構建和生成步驟，並在清單文件中聲明依賴關係。爲了在別的項目中起到依賴項的作用，項目還必須在manifest.xml文件中聲明導出屬性，這很容易出錯並導致交叉編譯失敗。這個問題是應當盡力避免的。
catkin仍然使用包的清單文件，但其被稱爲package.xml。使用catkin，不再使用Makefile，作爲替換，CMakeLists.txt文件是強制的。要作爲依賴項，catkin自動生成配置文件，而不是使用人工製作的導出標誌。開發人員需要在CMakeLists.txt中提供安裝目標，這意味着他們必須指定要安裝哪些文件，哪些文件不安裝。這允許大大減少ROS包的下載/更新的大小。
CMakeLists.txt文件中使用的ROS特定宏命令在名稱和結構上都在rosbuild和catkin中發生了變化，遷移必須手動完成，只有有限的工具支持。
package.xml和mainfest.xml文件具有不同的語法。
這些變化主要是實現設計目標所必需的。開發人員受益於配置文件的自動生成，用戶從ROS包的增加的可移植性中受益。
