vscode运行ada代码必须依赖gprbuild和.gpr项目文件，不能单文件直跑；需配置tasks.json调用gprbuild并指定-p路径，launch.json中target和midebuggerpath须准确指向生成的可执行文件与gdb调试器。
gprbuild 是运行 Ada 代码的核心命令，但 VSCode 本身不直接“运行” Ada —— 它靠调用 GNAT 工具链完成编译、链接和执行。只要 gprbuild 能在终端里成功生成可执行文件，VSCode 就能通过任务（tasks.json）触发它；但若跳过项目定义或路径配置错误，gprbuild 会报错退出，根本不会生成 .exe 或可执行文件。
必须先有 .gpr 项目文件，不能只写 .adb
Ada 不像 C/Python 那样支持单文件直跑。gprbuild 强依赖 .gpr（GNAT Project）文件来声明主程序、源码路径、编译开关等。常见错误是：新建 hello.adb 后直接点“运行”，结果提示 no project file found 或 project file not specified。
-
hello.gpr至少要包含for Main use ("hello.adb");和for Object_Dir use "obj"; - 文件名必须与
project声明一致（如project Hello is→ 文件名应为hello.gpr，大小写敏感） - 不要把
.gpr放在子目录里——gprbuild默认只在当前工作目录找，除非显式用-P path/to/project.gpr
tasks.json 里 command 必须是 gprbuild，不是 gcc 或 gnatmake
虽然 GNAT 底层用 gcc 编译，但 Ada 项目管理必须走 gprbuild 流程。用 gnatmake 会绕过项目配置，丢失库依赖、交叉编译目标等关键信息；用裸 gcc 更不可行，它无法解析 Ada 的契约、泛型实例化或 SPARK 模式。
-
"command": "gprbuild"，不是"command": "gnatmake" -
"args"中必须带-P ${workspaceFolder}/xxx.gpr，不能省略-P - 加
-p参数确保自动创建obj/目录；加-q可减少冗余输出，便于问题定位
launch.json 调试前务必确认 target 路径和 gdb 路径正确
VSCode 的 Cortex-Debug 或 GDB 扩展启动时，如果 target 指向不存在的文件（比如 obj/hello.exe 但实际生成的是 obj/hello），或 miDebuggerPath 指向 Windows 下的 gnat.exe（它不是调试器），就会卡在 “launching…” 或报错 Failed to launch: cannot find executable。
-
target必须严格匹配gprbuild输出的可执行路径，Linux/macOS 无后缀，Windows 通常有.exe -
miDebuggerPath必须指向gdb，不是gnat或gcc；交叉开发时要用arm-none-eabi-gdb，而非主机gdb - 嵌入式场景下，
preLaunchTask必须设为构建任务名（如"build"），否则调试器可能加载旧二进制
Ada 插件报“no language server found”多半是 GNAT 没进 PATH
“Ada Language Server” 扩展启动时会尝试调用 gnatls。如果终端里能跑 gprbuild，但 VSCode 里插件持续报错，大概率是 VSCode 启动时没继承系统 PATH —— 尤其在 macOS/Linux GUI 启动、或 Windows 从开始菜单启动时。
- Linux/macOS：用终端执行
code --no-sandbox --unity-launch启动 VSCode，确保环境变量完整 - Windows：检查
gnatls --version是否能在 VSCode 内置终端中执行；不行就手动在settings.json里加"ada.languageServerPath": "/path/to/gnatls" - 不要依赖插件自动探测 —— 显式指定路径比猜更可靠
gprbuild 成功不代表代码能跑通；gdb 启动成功也不代表断点能命中。Ada 的编译期检查（范围、溢出、任务并发）和运行时检查（-gnato）全靠工具链配置驱动，VSCode 只是管道。漏掉 .gpr 的 package Compiler 设置，或 tasks.json 里没传 -gnato，后面所有调试都可能掩盖真正的问题。
