1. 跨平台编译概述

大家好，我是你们这门课的主讲。今天咱们聊聊跨平台编译——说白了，就是让同一份代码，能在 Windows、Linux、macOS 甚至嵌入式系统上都能编译通过、跑起来。

你可能觉得这有什么难的？我刚开始工作那会儿也这么想。直到有一次，我在 Linux 上写了一个网络库，同事在 Windows 上一编译，报错一百多个……嗯，从那以后，我就再也不敢小看跨平台这件事了。

什么是跨平台编译

跨平台编译，简单讲就是：一套源码，多套编译目标。

你写的是 C++ 代码，但最终要生成 Windows 上的 .exe、Linux 上的 ELF 可执行文件、macOS 上的 .app 包。甚至可能还要交叉编译到 ARM 嵌入式板子上。

这里有个关键点：跨平台编译 ≠ 跨平台运行。前者是编译阶段的事，后者是运行时的事。我们这门课主要讲前者。

核心概念：跨平台编译关注的是「如何让编译器在不同操作系统、不同架构上，用同一套构建脚本，产出正确的二进制文件」。

为什么需要跨平台

你可能会问：我就在 Windows 上开发，为什么要折腾跨平台？

我遇到过不少团队，一开始只支持 Linux，后来客户要求 Windows 版本，结果整个项目重构了三个月。说白了，跨平台不是锦上添花，而是技术债的提前偿还。

具体来说，有这几个场景：

团队协作：有人用 macOS 写代码，有人用 Windows 测试，CI 服务器跑 Linux。没有跨平台编译，你连 PR 都合不进去。
产品分发：你的软件要同时发布 Windows 版和 Linux 版。总不能维护两套 Makefile 吧？
嵌入式开发：在 x86 上编译，部署到 ARM 上运行。这就是典型的交叉编译，也是跨平台编译的一种。
开源项目：你的项目如果只支持一个平台，社区贡献者会少一大半。

我的建议：哪怕你现在的项目只跑在一个平台上，也建议从一开始就用跨平台工具链。我见过太多「先跑起来再说」的项目，最后重构成本比重新写还高。

主流跨平台工具链介绍

市面上跨平台构建工具不少，我挑三个最主流的讲讲。这三个我都深度用过，各有各的脾气。

CMake

CMake 是目前 C++ 社区的事实标准。你想想看，连 Qt、LLVM、OpenCV 这些巨无霸项目都用它，说明它确实能打。

CMake 的工作方式是：你写 CMakeLists.txt 描述构建规则，CMake 根据目标平台生成对应的构建文件（比如 Linux 上的 Makefile，Windows 上的 Visual Studio 工程文件）。

# 一个简单的 CMakeLists.txt
cmake_minimum_required(VERSION 3.16)
project(MyApp LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(myapp main.cpp utils.cpp)

# 跨平台处理
if(WIN32)
    target_compile_definitions(myapp PRIVATE PLATFORM_WINDOWS)
elseif(APPLE)
    target_compile_definitions(myapp PRIVATE PLATFORM_MACOS)
else()
    target_compile_definitions(myapp PRIVATE PLATFORM_LINUX)
endif()

我个人习惯用 CMake 的 Presets 功能来管理不同平台的配置。这样团队成员不用记一堆命令行参数。

注意：CMake 的语法比较「古老」，尤其是变量作用域和函数定义，容易踩坑。我曾经因为一个 set() 没加 PARENT_SCOPE，排查了整整一个下午。

Meson

Meson 是后起之秀，设计理念就是「快」和「干净」。它的构建描述文件是 Python 风格的 DSL，比 CMake 的语法友好很多。

Meson 的编译速度确实快，尤其是增量编译。我有个项目用 CMake 要 40 秒，换成 Meson 后 15 秒搞定。

# meson.build
project('myapp', 'cpp',
  version: '1.0.0',
  default_options: ['cpp_std=c++17'])

executable('myapp',
  'main.cpp',
  'utils.cpp',
  dependencies: [],
  install: true)

# 跨平台条件判断
if host_machine.system() == 'windows'
  executable('myapp_win', 'win_specific.cpp')
endif

Meson 的缺点也很明显：生态不如 CMake 成熟。很多第三方库的 wrap 文件要么没有，要么维护不及时。

Bazel

Bazel 是 Google 开源的构建工具，特点是可重现构建和分布式编译。Google 内部几乎所有 C++ 项目都用它。

Bazel 的沙盒机制保证了每次构建都是干净的，不会因为本地环境不同导致「在我机器上能跑」的问题。

# BUILD
cc_binary(
    name = "myapp",
    srcs = ["main.cpp", "utils.cpp"],
    copts = ["-std=c++17"],
    deps = [
        "//libs:common",
    ],
)

# 跨平台配置
config_setting(
    name = "windows",
    constraint_values = ["@platforms//os:windows"],
)

cc_binary(
    name = "myapp_win",
    srcs = ["main.cpp", "utils.cpp", "win_specific.cpp"],
    copts = select({
        ":windows": ["-DWIN32"],
        "//conditions:default": [],
    }),
)

不过 Bazel 的学习曲线比较陡。我刚开始用的时候，光理解 WORKSPACE 和 BUILD 文件的关系就花了两天。

工具链对比

特性	CMake	Meson	Bazel
学习曲线	中等	低	高
构建速度	中等	快	快（增量）
生态成熟度	极高	中等	高（Google 生态）
跨平台支持	全平台	全平台	全平台
可重现构建	需手动配置	部分支持	原生支持
适合场景	通用 C++ 项目	中小型项目	大型/分布式项目

知识体系总览

下面这张图，是我梳理的跨平台编译核心知识体系。你可以把它当作这门课的地图。

这张图把跨平台编译拆成了三个维度：为什么需要、核心概念、主流工具链。后面的章节，我们会沿着这三个维度深入展开。

我的建议：如果你是新手，先从 CMake 入手。生态最全，遇到问题随便一搜就有答案。等你把 CMake 玩熟了，再去看 Meson 和 Bazel，会更容易理解它们的设计取舍。

好了，这一章就到这里。记住一句话：跨平台编译不是技术问题，而是工程管理问题。工具只是手段，关键是你的项目从一开始就要有跨平台的意识。

可可精品资料库

📚 课程目录

1. 跨平台编译概述

什么是跨平台编译

为什么需要跨平台

主流跨平台工具链介绍

CMake

Meson

Bazel

工具链对比

知识体系总览