02-开发工具

gdbgdb是gcc工具链中的调试器，本身是个命令行的可执行程序，以往我们用vscode、Qt Creator调试程序的时候，底层用的都是gdb工具，不过这些IDE把他的数据给可视化了 1.gdb中常见指令启动与连接 命令 说明 gdb <executable> 启动GDB并加载可执行文件 gdb -p <pid> 附加到正在运行的进程 target remote :<port> 连接远程gdbserver（常用于嵌入式调试） target remote /dev/ttyUSB0 通过串口连接目标板（如ARM开发板） 断点与观察点 命令 说明 break <function> 在函数入口设断点（如 break main） break *<address> 在内存地址设断点（如 break *0x8000） break <file:line> 在指定文件的某一行设断点（如 break driver.c:42） watch...

ClaudeCode参考链接：Claude Code 项目目录结构 | 菜鸟教程 避免权限请求使用ClaudeCode时，会发现它总是请求各种命令的权限，非常烦人。可以通过以下方式让他获取所有工具的权限 1claude --allow-dangerously-skip-permissions 基本结构claudecode有多种概念，比如skill、subagents…他们基本上都作为独立的文件存在于对应的目录，Claude Code 会在特定位置查找对应的配置文件 12345678910111213141516171819202122your-project/├── CLAUDE.md ← 团队共享指令，提交到 git├── CLAUDE.local.md ← 个人覆盖，被 git 忽略└── .claude/ ├── settings.json ← 权限 + 配置，提交到 git ├── settings.local.json ← 个人权限，被 git 忽略 ...

git使用笔记1.用户初始化12git config --global user.name "Li-Ruiqi"git config --global user.email "1009962019@qq.com" 提交代码时会显示这里配置的user的信息 不加--global也行，就是配置当前仓库 2.提交一个PR12345git checkout -b feature/xxx # 创建新分支并切换# 进行代码修改git add.git commit -m "提交信息"git push origin feature/xxx 3.切换到某个提交(commit) 如果check out到当前最新节点之前的某个节点，修改代码并提交，再切换回最新节点，会发现刚才的commit消失了，并没在该分支中 12345678910# 列出提交历史来找git graph中消失的commitgit log# 或者git reflog#切换git checkout...

软件开发方法论企业中的软件开发不是像我之前那样，有个idea就直接开始编码，而是先写好一个完善的文档，其他人照着文档进行开发的。我们在Vibe Coding的时候，最好也用这种方式，把需求边界进行最大程度的约束，这样可以有效提高AI生成代码的可用性，减少返工成本 基本流程：产品需求文档（PRD）—>软件需求规格（SRS）—>系统架构设计（SAD）—>详细设计（SDD）—>编码实现 产品需求文档产品需求文档重点回答三个核心问题: 1.市场上存在什么问题?(市场背景与机会) 2.我们要为谁解决?(目标用户画像) 3.我们要做什么/不做什么?(产品范围与优先级) 产品需求文档的目的与范围： 用于定义项目的市场需求边界，明确立项目标、目标用户、产品范围及阶段性约束，并作为后续软件需求规格(SRS)、系统架构设计和测试规划的输入 产品需求文档的作用： 给所有人建立项目共识，定义好产品、技术的边界

Autoconf定义Autoconf是一个自动化构建的CLI工具，用于生成可移植的configure脚本。configure脚本会完成以下事情： 根据configure.ac文件定义的规则，运行时自动检查系统环境：操作系统、编译器、库、函数、头文件、字节序、路径等 根据检测结果及用户输入生成Makefile （通常需要一个Makefile.in 模板，由automake工具提供） 123456789源码目录 ├── configure.ac ├── Makefile.am │ ├─> automake 生成 Makefile.in ├─> autoconf 生成 configure │ ./configure 生成 Makefile（结合 Makefile.in + 系统检测结果） └─> make 编译安装 AutoConf有以下特性： 跨平台性强：自动适配不同 Unix/Linux 系统 减少手动维护：不需要为每个平台写单独...

Makefile总览定义：Makefile是一个自动化编译工具，用于定义文件依赖关系与构建规则 Makefile里主要包含了五个东西：显式规则、隐晦规则、变量定义、文件指示和注释 显示规则显式规则说明了，如何生成一个或多的的目标文件。这是由Makefile的书写者明显指出：要生成的目标，目标的依赖文件，生成的命令。其格式如下： 12目标: 依赖文件 命令 # 必须用Tab缩进 make 会检查目标文件的时间戳，若依赖文件比目标新，则重新执行命令 若目标文件已存在且依赖无变化，跳过构建（增量编译） 1.伪目标：用于执行非文件生成的操作（如清理、安装等），需通过 .PHONY 显式声明 12345.PHONY: clean installclean: rm -f *.o appinstall: cp app /usr/local/bin/ 2.默认目标：一个Makefile中可以定义多个目标，当我们使用make命令但不指定具体的目标时，默认生成第一个目标 3.中间文件目标：临时生成的文件（如 .o 文件），可通过 .INTERMEDIATE...

CMake基本用法1.CmakeListsCmakeLists.txt是 cmake 的构建定义文件，如果工程存在多个目录，需要确保每个要管理的目录都存在一个CMakeLists.txt 2.CMake的语法 现代CMake和之前CMake的区别： 现代CMake是面向Tartget的，什么添加头文件、库的路径都是针对某个Target添加而不是对整个目录都添加进去。 cmake_minimum_required() 添加CMake编译的最低版本 project() 命名该CMake工程 add_executable(<name> [source1] [source2 ...]) 指定该工程编译将生成.exe的可执行文件 add_library(<name> [STATIC|SHARED|MODULE] [source1] [source2 ...]) 指定该工程编译生成静态/动态库 aux_source_directory(dir...

find_package()的用法作用主要就是通过库对应的.cmake文件（由库的维护者提供，一般用不着自己写），获得第三方库的头文件以及动/静态库文件的路径，方便我们直接添加到我们自己的工程里面 <PackageName>_FOUND ：找到了就是True，没找到就是未设定 <PackageName>_INCLUDE_DIR ：头文件目录 <PackageName>_LIBRARY...

CMake工程结构如果项目比较简单，比如只有一个CMakeLists.txt或者projet，那么就不用特别关心这个。但是如果一个大工程，有多个可执行文件，或者又有可执行文件，又有静态/动态库，则需要写多个CMakeLists.txt 多个CMakeLists如何写一般最外层的CMakeLists写： 1.设置编译后输出的位置 2.设置整个工程的C++版本 3.add_subdirectory() 什么时候写projet()一般只有最外层的CMakeLists写一下projet()。每写一个projet()，就会生成一个.sln文件。单独打开就如右图所示。左图是最外层的.sln文件 如果用VS的话，每个project就可以单独编译，但如果用的是VSCode的话，即使不写project每个subdirectory也可以单独编译，所以就没必要写了

软件开发基本流程软件开发流程是标准化的项目实施框架，核心围绕 “需求落地 - 开发实现 - 测试验证 - 上线运维” 闭环推进，结合你当前的 i.MX6ULL 智能车载终端项目，具体流程及关键节点如下： 1.需求阶段 需求收集与调研：对接产品、车载场景用户（车企 / 终端用户），明确核心诉求（如你文档中的导航、CAN 总线交互、宽温适配等），同步调研行业标准（GB/T 车载规范）、竞品功能、技术可行性（i.MX6ULL 芯片性能边界）。 需求分析与梳理：筛选有效需求，区分核心功能（必做）与可选功能（选配，如 4G/5G 模块对接），明确需求优先级，规避功能冲突（如多媒体与倒车影像切换逻辑）。 需求文档输出：即你当前的《需求规格说明书》，明确功能、硬件适配、性能、合规性等要求，作为全流程依据，需组织多方评审（开发、测试、产品）确认，避免歧义。 需求分解：将整体需求拆解为可落地的细分任务，按模块拆分（如软件层拆分为驱动层、中间件层、应用层），每个任务明确目标、产出物、时间节点，适配 i.MX6ULL 项目的硬件绑定特性（如 CAN 驱动开发、LVDS...