1. 先从gmake这条报错说起
CCS全称Code Composer Studio，是TI官方推出的集成开发环境，底层基于Eclipse构建，编译系统却不像很多Eclipse系IDE那样走内置的增量编译器，而是调用了外部构建工具gmake。用过CCS的人八成都在Console窗口里见过这句话：
gmake: *** [all] Error 2 gmake: Target 'all' not remade because of errors第一次碰上这个提示，说实话我也慌了一下，以为是工程文件坏了，或者CCS本身出问题了。后来排查的次数多了才意识到，这句话压根不是“病因”，而是“病情通报”。gmake的意思是：它知道目标all没有构建成功，但真正的错误原因它不管，也不负责打印，它只会把具体错误留给编译器或者链接器，自己在最后补一句“反正没编出来”。
换句话说，如果你只盯着这行字去搜解决方案，很容易跑偏。正确的思路是往上翻日志，找到真正报错的error、warning、undefined symbol，那才是需要动手的地方。
这篇内容适合谁看？刚入手DSP开发、正在用CCS做28335或28379D之类项目的同学，以及被CCS编译问题折磨过的嵌入式工程师。我会按“报错机制、快速定位、逐类排查、实操案例、避坑心得”这个顺序来写，尽量把每个容易踩坑的点都说透。
2. 弄懂gmake报错机制是解决问题的第一步
2.1 gmake的工作方式与“Target not remade”的含义
先用大白话解释一下gmake到底在干什么。CCS在编译工程时，本质上是根据工程配置生成了一个Makefile，然后调用gmake按依赖关系逐个执行编译和链接命令。每个编译好的源文件对应一个目标文件（.obj），所有目标文件再加链接脚本、库文件，最终合成一个.out。
“Target 'all' not remade because of errors”这句话里，all是Makefile里最顶层的目标。gmake的规则是：如果依赖的某个步骤失败了，它不会继续做后续步骤，因为后续步骤依赖前面步骤的结果。比如某个.c文件编译失败，那对应的.obj就不会生成，链接步骤没有.obj可用，自然也不能执行。
关键在于：gmake只负责调度，不负责解释错误。它把真正的错误信息打印在“not remade”之前的那几行里，可能是编译器报的，也可能是链接器报的。所以排查原则很简单——往上翻，永远不往下翻。
2.2 打开详细的编译输出日志
很多人遇到报错后，Console里只显示了一小段信息，原因是从CCS默认的Build Console里看到的输出经过了过滤。为了看清楚完整日志，建议在CCS里按下图路径设置：右键工程 -> Properties -> Build -> C2000 Compiler / C2000 Linker -> 在Diagnostic Options里，把所有Diagnostics级别调到All，同时把“Treat chained warnings as errors”这类选项关掉。
另一个实用技巧是用命令行方式手动触发构建。在CCS安装目录下能找到工程对应的makefile（通常在工程的Debug或Release目录里，名字可能叫makefile或者subdir_rules.mk）。打开命令行工具，切到该目录，手工执行：
gmake all这样输出不会被IDE吞掉，出错时能直接看到编译器原始报错，权限问题、环境变量问题也更容易暴露出来。每次我遇到Console输出不完整的情况，都会用这个办法，基本五分钟内能定位到真正的原因。
2.3 学会区分编译错误与链接错误
gmake说“Target all not remade”，背后可能是编译错误，也可能是链接错误，这两种的解决路径完全不同，必须提醒一下。
编译错误通常出现在某个.c文件上，比如语法写错、找不到头文件、宏定义缺失。报错行会带有源文件名和行号，类似：
subdir_rules.mk:9: recipe for target 'main.obj' failed main.c:17: error: unterminated comment链接错误则出现在所有源文件都编译完成后，但最后合成.out时出了问题，常见的像“undefined symbol”“cannot find library”“relocation value overflow”等。链接错误不会指向某个源文件，而是指向某个符号或某段地址：
error #10234: unresolved symbols remain先分清这两类，后面排查才能有的放矢。很多初学者看到一堆红字就慌，其实先看一眼错误属于哪一类，问题已经解决了一半。
3. 快速定位真凶：教你一眼看穿核心报错
3.1 常见报错信息对照速查表
我整理了CCS中gmake终止前最常见的几类核心报错，方便大家直接对照：
| 错误类型 | 典型输出 | 意思与方向 |
|---|---|---|
| 语法错误 | main.c:23: error: expected ';' before '}' token | 源文件语法问题，去对应行检查 |
| 头文件缺失 | fatal error: DSP2833x_Device.h: No such file or directory | 包含路径没配置好 |
| 未定义符号 | error #10234: unresolved symbols remain | 链接阶段找不到函数或全局变量定义 |
| 重复定义 | error #10056: symbol "InitGpio" redefined | 多个源文件重复实现了同一个符号 |
| 内存溢出 | error: program will not fit into available memory | 段分配超出芯片RAM/Flash空间 |
| 找不到库文件 | error: cannot find -llibc.a | 库路径或库文件名配置有误 |
| 权限问题 | permission denied或failed to open ... for writing | 输出目录不可写，或被占用 |
| 磁盘空间 | No space left on device | 临时目录/工程目录空间不足 |
把核心问题定位成这个表格里的某一类，再去搜索或处理，效率会高很多。
3.2 在Build Console里快速提取有效信息
很多人打开Console就是一片红，眼睛盯久了容易花。我的习惯是：先看出现“error #”或者“fatal error”的行，这些是编译器明确标记的错误；再看“recipe for target”上方的recipe行，那行会告诉我们执行的是哪条命令、哪个目标文件。
举个例子，Console输出里有类似这样的内容：
C:/ti/ccs1040/ccs/tools/compiler/ti-cgt-c2000_20.2.5.LTS/bin/cl2000 ... --compile_only --c99 ... main.c >> ERROR: main.c line 12: illegal character 'a' (0x61) gmake: *** [main.obj] Error 1 gmake: Target 'all' not remade because of errors这里重点就是>> ERROR: main.c line 12，说明冲突字符出现在main.c第12行，而不是最下面的gmake提示。用这种方法，我通常能在几十行日志里10秒内锁定问题源。
还有一种情况是Console里大量warning，夹杂着少量error。建议优先处理error，warning先忽略。有些warning在编译阶段不影响生成.obj，但到链接阶段可能变成error，比如变量未初始化、隐式声明等，这类warning要在编译器选项里开启“对待警告为错误”才能强制暴露，不建议默认开启，否则会影响调试效率。
3.3 用搜索和过滤技巧处理超长日志
工程大了以后，一次构建可能输出几百行日志。肉眼翻太慢，推荐两个方法：
- 在Console窗口里右键，选择“Find”，输入“error”，逐个查找；或按Ctrl+F通过搜索框定位。
- 把Console内容全选复制到文本编辑器里，用正则搜索
error、undefined、not found等关键词。
我个人的偏好是复制到VS Code里搜，因为能看到上下文，还能对比多个error之间的共同规律。有些报错看起来孤立，比如反复出现“cannot find”，十有八九就是某个路径配置错了，系统性解决比一个个patch要靠谱。
4. 逐类排查：从工程配置到代码问题的完整路径
4.1 第一步：清理工程并重新构建
遇到任何编译问题，第一件事永远是Clean。因为CCS的增量编译在某些情况下会保留过期中间文件，源文件改了但依赖关系没刷新，结果就是奇奇怪怪的编译状态。
操作方式：Project菜单 -> Clean... -> 选中当前工程，CCS会先删除Debug或Release目录下的中间文件，再重新编译。
如果有命令行习惯，也可以用：
gmake clean gmake all清理之后再看报错是否复现，如果问题消失，说明是中间文件缓存或依赖关系更新不及时导致的；如果问题依旧，那才是真正的代码或配置问题。
这里要强调一个细节：Clean之后重新编译是完整编译，不是增量编译，耗时会长很多，但信息也更全面。不要怕麻烦，这一步能过滤掉大概三分之一的“假故障”。
4.2 第二步：检查编译器与链接器选项
CCS工程里每个Build Configuration（比如Debug和Release）都有一套独立的编译选项。常见的坑包括：
- 优化级别不一致导致某些代码行为异常；
- C标准版本选错，导致部分语法不支持；
- 浮点模式或内存模型配置与芯片不匹配；
- 头文件路径遗漏或错误。
例如DSP28335，工程属性里C2000 Compiler -> Include Options至少需要把芯片支持包的头文件目录加进去，比如D:/ti/controlSUITE/device_support/f2833x/v142/DSP2833x_headers/include。如果漏配，所有包含DSP2833x_Device.h的源文件都会报“No such file or directory”。
链接器方面重点检查Linker -> File Search Path里的库搜索路径和库文件。芯片支持包里通常有rts2800_fpu32.lib或rts2800_ml.lib，用错库也会导致大量undefined symbol。
查找技巧：把错误信息里的某个符号名复制到IDE的搜索框里搜整个工程，看看这个符号定义在哪个文件里，然后对比工程里是否包含了那个源文件，或者头文件声明和实现是否匹配。
4.3 第三步：核对工程依赖与源文件排除情况
CCS工程左侧的Project Explorer里，每个文件夹和源文件都能单独设置是否参与构建。右键点某个源文件 -> Properties -> Build -> Exclude from build，如果勾上了，这个文件就不会被编译。
有时候为了调试临时排除了某个文件，事后忘了加回来，链接阶段就会报一堆未定义符号。针对这类问题，最直接的排查方式是在Project Explorer里逐个检查源文件有没有被排除，尤其要注意那些原本应该参与构建的.c文件。
工程引用（Project References）也是一个隐藏坑。当多个工程相互依赖时，比如库工程和主工程分开存放，主工程必须在Properties -> Project References里勾选对应的库工程，才能依赖库工程的最新构建结果。否则使用的是旧库文件，或者干脆找不到库文件。
4.4 第四步：检查文件系统与路径问题
这部分看起来低级，但实际发生频率超高。
第一，工程路径不能有中文、空格和特殊符号。CCS的工具链基于gmake，老版本对路径中的空格处理并不友好，经常出现“file not found”或“cannot open source file”这类误导性信息。尽量把工作区放在类似C:/ti/workspace的路径下。
第二，工程文件不能放在同步网盘或带权限管控的目录里。一位同事曾经把工程放在坚果云同步盘里，编译时经常报权限错误，Clean也不管用，后来把工程移到本地目录就正常运行了。原因是网盘客户端会锁定文件，gmake需要写入.obj时被系统拦截。
第三，Windows系统下要注意杀毒软件对CCS构建目录的实时扫描，会导致构建速度极慢甚至超时。可以在杀毒软件里把CCS安装目录和工作区目录加入白名单。
4.5 第五步：检查芯片型号和头文件配置是否匹配
CCS中新建工程时选择芯片型号，比如TMS320F28335、TMS320F28379D，这个型号会决定编译器预定义宏和链接时的段分配。
有一个很经典的坑：开发者把工程从28335迁移到28379D时，忘记修改工程属性里的Device型号，结果编译器还在用28335的预定义宏，而代码里包含的硬件寄存器头文件是28379D的，两者不匹配就会报出一大堆“undeclared identifier”之类错误。
排查方法：
- 右键工程 -> Properties -> General -> Device，确认型号正确；
- 确认工程引用的头文件支持包版本与芯片型号匹配；
- 在代码里打印或查看预定义宏，比如
__TMS320F28335__是否被正确定义。
4.6 第六步：CPU和内存资源问题
CCS编译大型工程时比较吃资源，内存不足会导致编译器进程被异常终止，gmake随之报“Target all not remade”。这种情况下Console里往往没有明确的error信息，只有一条类似“compiler terminated”的提示。
检查方法很简单，编译的时候打开任务管理器，看内存占用率是否接近100%，CPU是否被某个进程跑满。如果经常卡死，建议：
- 关闭不需要的浏览器标签页，释放内存；
- 把CCS的堆内存调大，在ccs.ini或启动参数里加上
-Xms256m -Xmx1024m； - 在工程Properties里开启并行构建，但要控制并行度，一般设为CPU核心数减1比较稳。
5. 两个典型实操案例：从报错到解决的全过程
5.1 案例一：DSP28335的LED闪烁工程报“undefined symbol”
一位刚开始学DSP28335的朋友，新建了一个LED闪烁工程，代码本身很简单：
#include "DSP2833x_Device.h" void main(void) { InitSysCtrl(); InitGpio(); while(1) { GpioDataRegs.GPADAT.bit.GPIO0 = 1; } }编译时报错：
undefined symbol: InitSysCtrl undefined symbol: InitGpio gmake: Target 'all' not remade because of errors这里的关键在于，InitSysCtrl和InitGpio这些函数的定义并不在头文件里，而是在支持包的源文件中，比如DSP2833x_SysCtrl.c、DSP2833x_Gpio.c。如果新建工程时没有把这些源文件添加进去，链接自然找不到符号。
解决办法是右键工程 -> Add Files，把controlSUITE里device_support对应芯片目录下的所有.c文件全部加入工程。注意不要勾上“Link to files”，直接复制到工程里更好管理。之后重新编译就通过了。
从这个案例可以总结出规律：“undefined symbol”优先去查符号定义所在文件是否被工程包含，而不是急着改代码。
5.2 案例二：工程路径调整后产生“file not found”
有网友把自己的CCS工作区从英文路径挪到了中文目录，比如D:/新工程/workspace，结果编译时报：
fatal error: cannot open source file "DSP2833x_Device.h" gmake: Target 'all' not remade because of errors初看以为是头文件路径不对，在Include Options里反复添加路径也没用。因为问题根源在于gmake在解析路径时无法正确处理中文字符编码，导致包含路径里的中文部分变成乱码。
最终解决办法是把整个工作区迁移回纯英文路径，比如C:/ti/workspace_dsp，然后在CCS里通过File -> Switch Workspace重新导入。这个问题在Windows + CCS环境下尤其明显，建议从源头避免，从一开始就别把工程放中文路径。
5.3 案例三：工程配置里误勾选了“Release”构建配置
还有人遇到一种情况：同一个工程，之前Debug配置编译正常，某天突然报错，怎么Clean都没用。后来发现问题是当前Active Build Configuration变成了Release，而Release配置从未正确配置过。
解决方法是Project -> Build Configurations -> Set Active -> Debug，把构建配置切回之前的配置。同时检查Release和Debug的编译选项差异，特别是预定义符号和优化选项。如果不需要Release配置，也可以右键工程 -> Properties -> Build -> Manage Configurations，删掉多余的配置。
这个案例提醒我，很多“突然报错”的问题根本不是代码变了，而是IDE配置被无意间改掉了。
6. 避坑经验与建议：长期稳定构建的关键
6.1 养成“看全日志”习惯
每次编译失败，先强迫自己看完Console里前20行，再动手改。很多人只看最后几行，容易把时间浪费在gmake的错误提示上。我看日志有一条经验：红色加粗的不一定是根因，但第一个出现error的位置大概率是根因。后面出现的Error往往是连锁反应。
6.2 稳定复现后再去改
不要在一次随机报错后立刻大改代码或配置。我的做法是：先记下当前报错信息，连做三次Clean + Build，确认是否稳定复现。如果偶尔不报，大概率是环境问题或者资源问题，先考虑杀毒、路径、内存占用这些方向；如果每次都报，再进入代码或配置排查。
6.3 建立最小化验证环境
遇到复杂报错时，建议新建一个最小工程，只放一个最简单的main.c，然后逐步往里面加源文件、加代码块，每次加一点编译一次。这样做能把问题收敛到某一个具体文件或配置项上。
比如怀疑某个头文件路径有问题，最小工程里直接写#include "xxx.h"，编译一次就知道路径对不对。这种方式比在几百个文件的大工程里反复猜要高效得多。
6.4 关于版本管理的一点建议
CCS工程里的.project、.cproject、Debug目录都不建议提交到Git，尤其是Debug目录里包含大量中间文件，提交后合并冲突会非常痛苦。建议Git忽略这些构建产物，只保留源代码、头文件、cmd文件和工程配置文件。
我个人的.gitignore模板里，CCS相关会加上：
Debug/ Release/ *.obj *.out *.map这样即使同事用了不同版本的CCS，也能减少工程文件差异导致的构建异常。
6.5 给新手的几条总结性建议
如果现在你正好被这个错误卡住，按顺序试试：
- 看完整日志，找出带
error的那一行； - 区分是编译错误还是链接错误；
- 确认工程路径没有中文和空格；
- 右键工程Clean，再重新构建；
- 检查源文件是否被排除构建；
- 检查芯片型号、编译选项、头文件路径是否匹配。
按这个顺序排查，绝大多数情况下都能解决问题。
7. 我个人在实际操作中的体会
和gmake、CCS打交道这些年，我最大的感受是：编译工具链就是个“性格直率”的助手，它不会帮你隐瞒任何错误，但也不会主动告诉你根因在哪。它把错误打印得又长又乱，其实是好事——信息都在那里，只看你愿不愿意花两分钟把关键信息捞出来。
每次有人把gmake那句“Target 'all' not remade because of errors”截图发我，我都先问一句：往上翻三行，你看到了什么？大多数时候，他们自己翻完就明白该怎么改了。
还有一点想多啰嗦：不要在同一个错误上反复硬试。如果同一个报错连续三次采用相同方式修改都没有效果，说明方向不对，停下来重新整理思路，或者去TI官方论坛搜一下对应错误码，往往比闷头折腾更有效率。
最后再分享一个小技巧：如果你经常在CCS里切换不同芯片型号的工程，建议把不同芯片的工程放置在不同工作区，避免CCS的工程元数据相互干扰。这个习惯帮我避免了很多莫名其妙的编译问题，也让工程管理清爽不少。
