3. 开发环境搭建

Slint 的工程化开发并不是“装一个 IDE 就能跑”的轻量流程，它同时涉及 Rust 与 C++ 两套语言工具链、Slint 编译器（slint-build / slint-compiler）、目标板交叉编译工具链，以及模拟器与真机两套调试通道。本节的目标是建立一条可复现、可验证、可迁移到 CI 的环境搭建路径，让后续章节的 UI 编译、渲染与部署都有稳定的基础。

一、核心原理：Slint 构建链路的三段式结构

Slint 的构建过程可以抽象为“声明式 UI 编译 → 语言绑定生成 → 目标平台链接”三段式链路。理解这条链路，才能判断环境搭建中每一步失败时应该检查哪一层。

• UI 编译层：.slint 文件由 Slint 编译器解析，生成 Rust 或 C++ 代码。Rust 侧通常通过 build.rs 调用 slint-build；C++ 侧通过 CMake 的 slint_target_sources 调用 slint-compiler。
• 语言绑定层：生成的代码依赖 slint crate 或 Slint::Slint CMake 目标，需要与宿主语言版本、ABI、目标三元组匹配。
• 目标平台层：最终链接到 Linux 桌面、嵌入式 Linux（如 ARM64）、MCU（如 STM32）或 WASM。不同目标需要不同的交叉编译器、系统根目录（sysroot）和渲染后端。

二、Rust 与 C++ 工具链安装

Rust 侧推荐使用 rustup 管理工具链，并显式固定版本，避免团队内 stable 漂移导致 Slint 宏展开差异。C++ 侧需要 CMake 3.21+、Ninja 以及支持 C++17 的编译器。

# Rust 工具链安装与固定
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustup toolchain install 1.79.0
rustup default 1.79.0
rustup target add aarch64-unknown-linux-gnu

# C++ 侧基础工具
sudo apt install -y cmake ninja-build g++ pkg-config
cmake --version   # 需 >= 3.21

验证 Rust 侧 Slint 可用性，可创建一个最小工程并检查 build.rs 是否成功生成绑定：

cargo new slint_probe && cd slint_probe
cargo add slint --features backend-winit,renderer-femtovg
# build.rs
fn main() { slint_build::compile("ui/app.slint").unwrap(); }
cargo build -vv 2>&1 | grep -i slint

C++ 侧则通过 CMake 引入 Slint，并确认 Slint::Slint 目标可被 find_package 找到：

find_package(Slint REQUIRED)
slint_target_sources(myapp ui/app.slint)
target_link_libraries(myapp PRIVATE Slint::Slint)

三、Slint 编译器配置与交叉编译环境准备

Slint 编译器既可以作为构建依赖自动调用，也可以独立安装用于预生成代码。交叉编译时，关键是让 slint-build 在宿主侧运行，而生成的代码与 Slint 运行库在目标侧链接。因此需要配置 .cargo/config.toml 指定 linker 与 runner，并为 C++ 侧准备 sysroot。

# .cargo/config.toml（ARM64 嵌入式 Linux 示例）
[target.aarch64-unknown-linux-gnu]
linker = "aarch64-linux-gnu-gcc"
runner = "qemu-aarch64 -L /usr/aarch64-linux-gnu"

[env]
SLINT_BACKEND = "winit-femtovg"

下表给出常见目标平台的工具链与 Slint 后端选择，便于按项目类型快速定位配置项。

四、模拟器与真机调试环境搭建

Slint 提供 slint-viewer 作为轻量模拟器，可在不编译完整应用的情况下预览 .slint 文件，非常适合 UI 迭代阶段。真机调试则依赖目标板上的运行环境、显示后端与调试代理。

# 模拟器预览
cargo install slint-viewer
slint-viewer ui/app.slint --backend winit-femtovg

# 真机部署（嵌入式 Linux）
scp target/aarch64-unknown-linux-gnu/debug/myapp root@192.168.1.20:/opt/
ssh root@192.168.1.20 "SLINT_BACKEND=linuxkms /opt/myapp"

真机调试建议同时保留两条通道：一条用于日志与性能计数（SLINT_DEBUG_PERFORMANCE=refresh_lazy），一条用于断点调试（gdbserver :2345）。这样可以在 UI 卡顿与逻辑错误之间快速区分。

五、误区与复盘

• 误区一：只装 Rust 不装 C++ 工具链。Slint 的 C++ 绑定与部分构建脚本仍依赖 CMake 与 C++ 编译器，缺失时会报 cmake not found 或链接失败。
• 误区二：交叉编译时在目标侧运行 slint-build。编译器必须在宿主侧执行，目标侧只接收生成代码与运行库。
• 误区三：忽略 sysroot 与 pkg-config。嵌入式 Linux 上缺少目标侧 libfontconfig、libinput 等依赖时，运行期会直接崩溃。
• 误区四：模拟器通过就认为真机通过。模拟器使用桌面 GPU 与窗口系统，真机可能使用 KMS/DRM 或软件渲染，必须分别验证。

建议在环境搭建完成后执行一次“最小闭环验证”：用同一份 .slint 文件分别构建桌面版与 ARM64 版，桌面版用 slint-viewer 预览，ARM64 版在真机启动并显示同一界面。只有这条闭环跑通，后续章节的 UI 组件、状态管理与性能优化才有可靠的实验基础。