为啥我的catkin老是出毛病，一编译就报错，搞得我头都大了。我这两天总算是把这堆破事儿捋清楚了，把一些最常遇到的坑给摸透了，今天就跟大家说道说道。
最开始搞ROS的时候，那真是啥都懵。建了个工作空间，写了个节点包，然后习惯性地敲下catkin_make，回车，然后就是一堆红色错误蹦出来，看得人心慌。
第一个坑：找不着头文件
我发现很多时候是include路径没配你代码里写了#include <something/header.h>，但是catkin构建系统压根不知道这个something在哪。
- 检查：我得确保我依赖的包都写在里了，而且标签是对的，不能光顾着
exec_depend，还得看看有没有build_depend，不然编译的时候就找不到。 - Source 你的工作空间：这是最容易忘的。每次修改完*或者*，我都会习惯性地跑回工作空间根目录，然后执行
source devel/*。要是忘了这步，你的新包或者新依赖根本进不了环境，编译自然就出问题。
第二个坑：* 写错了
这个文件简直是重灾区。我最开始总是在add_executable和add_library后面忘了写链接库（target_link_libraries）。
比如我写了个C++节点，需要用到TF库，我当时就只写了可执行文件，然后编译就报错，说找不到TF相关的函数。
我赶紧回头看，找到我加的那个节点名字，然后加上了：
target_link_libraries(我的节点名 ${catkin_LIBRARIES})加上这个，再跑catkin_make，情况就好多了。还有就是，如果你用了ROS的消息生成器或者Action，一定要确保在find_package后面，调用了catkin_package，并且在catkin_package里声明了需要的依赖，不然运行时会找不到消息定义。
第三个坑：编译缓存和环境混乱
有时候明明代码是对的，配置也是对的，就是编译报错，而且报错信息特别奇怪，像是在用一个旧版本的库。这基本就是CMake的缓存搞的鬼。
我直接采取最暴力的办法：删了重来。
# 切换到工作空间根目录
rm -rf build/
rm -rf devel/
catkin_make
删掉build和devel目录，相当于把猫崎（catkin）的记忆全部清空。重新执行catkin_make，这回它会从头开始解析所有的CMake文件，依赖检查也会重新来一遍。这样做百分之九十的问题都能解决。
第四个坑：工作空间嵌套问题
这个我踩过一次大坑。我有一个老项目A，在一个工作空间WorkA里。然后我新建了个WorkB，想用WorkA里的某个包，就直接把WorkA的src文件夹复制进WorkB的src里了。然后我直接在WorkB里跑catkin_make。
结果就是编译报错，说找不到依赖的库，或者找不到包的定义。因为猫崎默认只构建当前工作空间下的包，它不处理跨工作空间引用的复杂情况。
我是这么解决的：我没有嵌套src，而是让WorkB的依赖WorkA，然后在WorkB的里，source了WorkA的。这样，WorkB在编译时，环境里就有WorkA的路径了，编译一下子就通顺了。
现在回头看，大部分报错无非就是路径找不到、依赖没声明、环境没source这三板斧。把这几个点摸清楚了，catkin报错的频率就大大降低了。
