9、生成可执行文件：add_executable的进阶用法，WIN32/MACOSX_BUNDLE属性

说实话，add_executable 这个命令，很多新手觉得它就是个「生成exe」的工具。嗯，从功能上讲没错，但它的进阶用法——特别是 WIN32 和 MACOSX_BUNDLE 这两个属性——才是真正区分「能用」和「会用」的分水岭。

我最早接触 CMake 时，也以为加个 add_executable 就完事了。直到有一次在 Windows 上编译一个带 GUI 的程序，双击 exe 文件，控制台窗口也跟着弹出来……那画面，说实话挺尴尬的。后来我才知道，原来 WIN32 属性就是用来解决这个问题的。

add_executable 的基本形态

先回顾一下最基础的用法：

add_executable(myapp main.cpp)

这条命令会生成一个可执行文件。在 Windows 上叫 myapp.exe，在 Linux 上叫 myapp，在 macOS 上叫 myapp。但这里有个隐藏的细节——它默认是「控制台子系统」程序。

什么叫控制台子系统？说白了，就是你的程序启动时，操作系统会先给你分配一个控制台窗口。如果你的程序是命令行工具，这完全没问题。但如果你写的是图形界面程序（比如 Qt、wxWidgets、或者纯 Win32 GUI），这个控制台窗口就很多余了。

WIN32 属性：让 Windows GUI 程序不再带黑框

解决方式很简单，加上 WIN32 关键字：

add_executable(myapp WIN32 main.cpp)

就这么一个词，编译出来的 exe 就变成了「Windows 子系统」程序。双击运行时，不会再弹出控制台窗口。我个人习惯在写任何 GUI 程序时都加上这个，哪怕只是测试用的 demo，也省得每次都要手动关掉那个黑框。

你可能会问：「那我的程序既需要 GUI，又需要打印调试信息怎么办？」嗯，我遇到过这个问题。我的做法是：开发阶段不加 WIN32，方便看控制台输出；发布时再加上。或者用 AllocConsole 和 AttachConsole 在运行时动态创建控制台——不过那是另一个话题了。

MACOSX_BUNDLE 属性：让 macOS 程序变成 .app 包

在 macOS 上，情况类似但又有不同。macOS 的应用程序通常是一个 .app 包——本质上是一个目录，里面包含了可执行文件、资源文件、图标、Info.plist 等。如果你不加任何属性，CMake 生成的就是一个普通的 Unix 可执行文件，双击它可能不会像预期那样启动。

要让 CMake 生成 .app 包，需要这样写：

add_executable(myapp MACOSX_BUNDLE main.cpp)

加上 MACOSX_BUNDLE 后，CMake 会自动生成 myapp.app/Contents/MacOS/myapp 这样的目录结构。你还可以通过设置 MACOSX_BUNDLE_INFO_PLIST 属性来自定义 Info.plist 文件。

if(WIN32)
    set(GUI_TYPE WIN32)
elseif(APPLE)
    set(GUI_TYPE MACOSX_BUNDLE)
else()
    set(GUI_TYPE)
endif()

add_executable(myapp ${GUI_TYPE} main.cpp)

两个属性的对比

你看，这两个属性虽然名字不同，但本质上是同一件事——告诉操作系统：「我这个程序不是命令行工具，别用终端的方式对待它。」

我曾经踩过的坑

讲几个我实际遇到过的坑，希望能帮你少走弯路。

坑一：WIN32 和 Qt 的冲突

有一次我用 Qt 写了一个小工具，加了 WIN32 属性。结果程序启动后，界面一闪而过就退出了。查了半天才发现，Qt 的事件循环需要控制台才能正常工作？不对，其实是 main 函数返回了。后来我意识到，WIN32 属性下，main 函数其实是 WinMain 的包装，如果入口点不对，程序会直接退出。解决方案是确保 Qt 的 QApplication 正确初始化，并且 exec() 被调用。

坑二：MACOSX_BUNDLE 和命令行参数

我记得有一次给 macOS 写一个工具，加了 MACOSX_BUNDLE 后，发现命令行参数传不进去了。这是因为 .app 包启动时，参数是通过 NSApplication 处理的，而不是传统的 argv。如果你需要同时支持 GUI 和命令行模式，建议不要加 MACOSX_BUNDLE，或者用 CFBundleGetMainBundle 来检测是否在 bundle 内。

坑三：跨平台条件编译

我曾经在 Linux 上不小心加了 WIN32 属性——嗯，CMake 不会报错，但会忽略它。Linux 上 WIN32 没有任何效果。同样，在 Windows 上 MACOSX_BUNDLE 也会被忽略。所以跨平台代码里，一定要用 if(WIN32) 和 if(APPLE) 包裹，别想当然。

实战：一个跨平台的 GUI 程序模板

下面是一个完整的例子，展示了如何用 CMake 构建一个跨平台的 GUI 程序：

cmake_minimum_required(VERSION 3.10)
project(GuiApp)

# 根据平台设置 GUI 属性
if(WIN32)
    set(GUI_FLAG WIN32)
elseif(APPLE)
    set(GUI_FLAG MACOSX_BUNDLE)
    # 设置 bundle 信息
    set_target_properties(gui_app PROPERTIES
        MACOSX_BUNDLE_GUI_IDENTIFIER "com.example.guiapp"
        MACOSX_BUNDLE_BUNDLE_VERSION "1.0.0"
        MACOSX_BUNDLE_SHORT_VERSION_STRING "1.0"
    )
else()
    set(GUI_FLAG)
endif()

# 添加可执行文件
add_executable(gui_app ${GUI_FLAG}
    main.cpp
    window.cpp
    window.h
)

# 链接必要的库
target_link_libraries(gui_app PRIVATE
    ${GUI_LIBRARIES}
)

这段代码里，我用了 set_target_properties 来设置 macOS 的 bundle 信息。如果你不加这些，CMake 会使用默认值，但建议还是显式设置一下，尤其是 MACOSX_BUNDLE_GUI_IDENTIFIER，这是 macOS 用来唯一标识你的应用的。

SVG 知识结构图

总结

WIN32 和 MACOSX_BUNDLE 这两个属性，说白了就是告诉 CMake：「我这个程序不是跑在终端里的，请用正确的方式打包它。」

我个人建议，只要你写的程序有图形界面，不管是用 Qt、wxWidgets 还是原生 API，都加上对应的属性。这不仅是规范问题，更是用户体验问题——你想想看，用户双击一个程序，结果先弹出一个黑框，是不是很掉价？

另外，别忘了跨平台的条件判断。我见过不少项目，在 Windows 上加了 WIN32，但在 macOS 上忘了加 MACOSX_BUNDLE，结果 macOS 用户拿到的是一个裸的可执行文件，连图标都没有。嗯，这种细节，往往决定了你的项目给人的第一印象。