简介q2c是一款面向Qt开发者的构建系统转换工具专用于在qmake的.pro工程文件与CMake的CMakeLists.txt之间双向转换解决团队协作或项目迁移中两种构建体系并存时的切换痛点。压缩包内共13个文件包含6个C源文件、5个头文件、1个qmake工程文件及1份README说明代码结构完整适合有一定Qt或C基础、需要在两种构建方式之间平滑迁移的开发者阅读。通过阅读源码可以清晰了解qmake与CMake在语法、跨平台能力、灵活性和生态支持上的差异掌握工具自动解析与生成工程配置的核心逻辑并可根据实际需求进行二次修改或扩展。整包仅14KB轻量易部署。已有3200余人学习下载对于正在从qmake过渡到CMake或希望对比两者实现原理的开发者是一份紧凑且实用的参考资料。1. 为什么从 qmake 迁到 cmakeq2c 到底在解决什么问题我遇到过一个 Qt5 老项目.pro文件里堆了五年平台条件分支win32:{}、unix:!macx:{}中间还夹着两个自定义函数和一堆exists()判断。构建本身没坏坏在它没法往外走——接 vcpkg 依赖、接新的 CI 流水线、切 Qt6每一步都被 qmake 的脚本风格卡住。q2c 就是这类问题的答案把.pro当作输入把 CMakeLists.txt 当作输出让存量 Qt 项目在不用手工重写构建脚本的前提下完成迁移。这个工具解决的不是“能不能编译”而是“构建描述怎么搬家”SOURCES、HEADERS、DEFINES、LIBS、CONFIG这些 qmake 变量要逐个落到 CMake 的 target 属性上平台条件分支要翻译成 CMake 的if(WIN32)、if(UNIX)。适合的人是手里有存量 Qt 代码、想统一构建系统但又不愿意一行行抄.pro的工程师。q2c 的产出不用一次到位能跑通、能对比、能逐步修正就已经值回投入。2. 读懂 .pro 和 CMakeLists.txt 的对应关系q2c 的转换依据2.1 qmake 变量不是键值对、*、条件赋值的作用域很多人第一次写转换脚本时会直接把.pro当成配置文件来解析逐行找SOURCES xxx然后收集字符串。这个思路在十行以内的 demo 工程上没问题一旦.pro里出现变量引用、条件赋值、函数调用逐行解析就会得出错误结果。qmake 的.pro本质是一段 QMake 脚本语言而不是 ini 配置。它的变量操作符有、、-、*、~语义各不相同。是覆盖是追加-是移除*是去重追加~是正则替换。同一个变量在文件不同位置被反复修改最终值取决于执行顺序。比如SOURCES src/main.cpp SOURCES - src/main.cpp SOURCES * src/main.cpp执行完这三行SOURCES的值是src/main.cpp因为先加后减再加第三行的*去重后没有产生重复。静态解析器如果只认就会在这里翻车。更隐蔽的是条件赋值。qmake 允许在赋值前加条件win32 { SOURCES src/win_utils.cpp } unix:!macx { SOURCES src/linux_utils.cpp }这实际上是作用域scope语法花括号不是随便写的格式它代表一个条件块。转换器必须把平台条件映射成 CMake 的if(WIN32)和if(UNIX AND NOT APPLE)而不是简单地把两行都收进源文件列表。还有一个容易忽略的细节变量展开顺序。qmake 中$$VAR在语句执行时立即展开如果变量在后面才被赋值前面引用处拿到的就是空字符串。这种“先用后定义”的写法在.pro里很常见尤其配合include()引入公共配置时转换器必须保留这种执行顺序语义否则生成出的 CMakeLists.txt 会丢掉一整批源文件。2.2 .pro 到 CMake 的六类映射表我把日常迁移中最常见、也是 q2c 必须处理的映射整理成一张表。这张表不是全部但覆盖了 90% 存量 Qt 工程的构建描述。.pro 写法CMakeLists.txt 对应写法注意点TEMPLATE appadd_executable(...)若是lib则用add_library(...)subdirs要单独处理TARGET myappadd_executable(myapp ...)或set_target_properties(... OUTPUT_NAME ...)可执行文件名的第一个参数QT core gui widgetsfind_package(Qt5 REQUIRED COMPONENTS Core Gui Widgets)Qt6 改成find_package(Qt6 ...)大小写敏感CONFIG c17set(CMAKE_CXX_STANDARD 17)还有c11、c14、c20DEFINES APP_VERSION\\\1.0\\\target_compile_definitions(... PRIVATE APP_VERSION\\\1.0\\\)转义要格外小心字符串里的引号必须保留INCLUDEPATH $$PWD/3rdpartytarget_include_directories(... PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/3rdparty)$$PWD对应的就是CMAKE_CURRENT_SOURCE_DIRLIBS -L$$PWD/lib -lfootarget_link_directories(...)target_link_libraries(... foo)qmake 直接传-lCMake 用目标名或全路径SOURCES src/main.cpp放进add_executable的源文件列表注意去重和路径展开HEADERS include/mainwindow.h同样放进add_executable或单独target_sources配合set(CMAKE_AUTOMOC ON)RESOURCES app.qrc放进源文件列表配合set(CMAKE_AUTORCC ON)这是 q2c 最容易漏掉的一项后面避坑章详说CONFIG consoleWindows 下不要设置WIN32_EXECUTABLE对应关系反直觉容易踩坑这张表看起来简单真正动手时麻烦全在边界Qt 模块名要区分大小写、源文件路径要统一成相对路径、CMake 的 target 属性要落在正确的PRIVATE/PUBLIC作用域里。2.3 函数与作用域qmake 里的“脚本味”是转换里最隐蔽的部分qmake 的.pro文件里通常还混着函数调用。contains()判断变量是否包含某个值count()统计元素个数exists()检查文件是否存在system()直接执行外部命令。这些在构建描述里都有对应语义但 CMake 侧要用不同的机制表达。最常见的例子是配置判断CONFIG(debug, debug|release) { DEFINES DEBUG_BUILD }这不是简单的“如果定义了 debug 就加宏”CONFIG(debug, debug|release)的意思是从CONFIG变量中取出当前生效的配置值把它和debug|release这个候选列表逐一比对。在 CMake 里这通常对应if(CMAKE_BUILD_TYPE STREQUAL Debug) target_compile_definitions(app PRIVATE DEBUG_BUILD) endif()但如果项目使用CMAKE_CONFIGURATION_TYPES这种多配置生成器CMAKE_BUILD_TYPE可能为空判断方式又要换成$CONFIG:Debug生成器表达式。q2c 在输出时最好默认生成表达式版本让单配置和多配置都能工作。自定义函数是另一个隐蔽点。qmake 允许用defineReplace()或defineTest()定义函数很多项目用它做路径拼接或编译开关判断。转换器遇到这类函数没有捷径得先把函数体拆开弄清楚它到底修改了哪个变量再改写为 CMake 的 function 或直接内联成变量操作。我一般建议在迁移时把这些函数手工收敛成 CMake 函数而不是让转换器去模拟 qmake 的函数调用栈——后者的实现复杂度会指数上升收益却为零。3. 先让 qmake 自己把变量展开转换的第一步不是写解析器3.1 为什么逐行正则解析不靠谱写 q2c 的第一版时我的想法是用正则把所有SOURCES 的行抓出来再处理掉$$PWD之类的变量引用。这个思路在简单工程里能跑但遇到三种情况就废了。第一种是include()。.pro文件经常拆成common.pri、win.pri通过include()引入主工程文件里看不到具体源文件列表。第二种是通配符例如SOURCES src/*.cppqmake 在解析时会自己展开目录里的文件正则抓到的只是一个星号。第三种是变量展开顺序——$$VAR在赋值语句执行时才解析而 qmake 的脚本执行顺序决定了哪些变量先有值。如果转换器一上来就写解析器会陷入“重新实现一个 qmake 解释器”的无底洞。正确做法是先借用 qmake 自己的能力把变量展开成最终值再做语法移植。3.2 用 qmake -query 和 -d 拿到展开后的变量清单qmake 自带调试选项可以直接利用。-query输出 Qt 安装路径相关的系统变量-d输出解析.pro的过程日志。qmake -query | grep -E QT_INSTALL_(LIBS|HEADERS|PREFIX)这条命令能拿到 Qt 的安装路径后面转换LIBS -lQt5Widgets这类写法时需要判断 5.15 还是 6.x路径不同find_package的参数也不同。qmake -d your_project.pro 21 | grep -E ^(Setting|Adding|Now)注意不同 qmake 版本的-d输出格式有差异不一定有Setting、Adding这几个前缀。我一般先跑一次把完整输出存到文件里再搜变量名qmake -d your_project.pro 21 qmake_debug.log grep -E SOURCES|DEFINES|INCLUDEPATH qmake_debug.log | head -50-d日志里能看到每次变量赋值前后的值包括include()引入的.pri文件里的赋值、平台条件块是否进入、$$VAR最终展开成什么。只要看到对应变量在某一处被追加了值就能确定它是“无条件”还是“只在 win32 分支下”。对于通配符可以写一个小.pro文件让 qmake 自己展开TEMPLATE aux SOURCES src/*.cpp message($$SOURCES)然后用qmake -d跑它输出里就是展开后的完整文件列表。这个文件不需要真的参与构建只是借 qmake 的变量展开能力当“计算器”用。运行前先备份原.pro避免误操作。3.3 用 QMAKE_SUBSTITUTES 思路生成模板展开完变量之后还有一条路可以绕开“自己写生成器”QMAKE_SUBSTITUTES是 qmake 内置的模板替换机制可以把文件中的占位符替换成变量值。把它用在转换里实际上是把.pro当作模板引擎来生成 CMakeLists.txt。做法是准备一个CMakeLists.txt.in模板里面写占位符cmake_minimum_required(VERSION 3.16) project(TARGET) set(CMAKE_AUTOMOC ON) add_executable(TARGET SOURCES HEADERS RESOURCES) target_include_directories(TARGET PRIVATE INCLUDEPATH) target_compile_definitions(TARGET PRIVATE DEFINES)然后在.pro文件末尾加一段QMAKE_SUBSTITUTES $$PWD/CMakeLists.txt.in CMakeLists.input $$PWD/CMakeLists.txt.in CMakeLists.output $$PWD/CMakeLists.txtqmake 处理时会读取.in文件把所有变量名替换为对应 qmake 变量的最终值输出成CMakeLists.txt。SOURCES会在生成时自动展开成空格分隔的文件列表。这个方案适合条件分支少、不需要映射平台判断的简单工程优点是几乎不用维护解析器缺点是模板里没法自动生成if(WIN32)结构遇到平台分支多的.pro还是得回到解析器路线。我一般把 QMAKE_SUBSTITUTES 作为快速摸底工具先跑一遍看看生成的 CMakeLists.txt 的源文件列表与make实际编译的文件列表是否一致不一致的地方就是需要手工处理的边界。4. 手写 q2c 转换脚本把 .pro 的构建描述搬进 CMakeLists.txt4.1 先做词法切分兼容续行、注释和引号真正的转换器我建议用 Python 写。第一件事不是提取变量而是把.pro文本拆成一条条逻辑语句。qmake 支持行尾反斜杠续行、#注释、双引号字符串切分时这三样都要处理。def split_statements(pro_text: str) - list[str]: statements [] buf in_string False i 0 while i len(pro_text): ch pro_text[i] if ch and not in_string: in_string True buf ch elif ch and in_string: in_string False buf ch elif ch # and not in_string: # 注释直接截断后续换行符不保留 while i len(pro_text) and pro_text[i] ! \n: i 1 continue elif ch \n and not in_string: if buf.strip(): statements.append(buf.strip()) buf else: buf ch i 1 if buf.strip(): statements.append(buf.strip()) return statements这个函数把.pro按行切分遇到#注释直接跳过直到换行遇到双引号则把行尾续行视为字符串的一部分。qmake 的\续行在读取原始文本时以\n形式存在由于换行符不吞掉反斜杠切分后能保留单条完整语句。参数说明in_string状态机是为了防引号内的#被误判为注释。qmake 里DEFINES APP_VERSION\\\1.0#2\\\这类写法虽然少见但一旦解析器把#后面的内容截断生成出的 CMake 宏定义就会少一截。做完这一步得到的是一串语法上独立的语句下一步就要区分这些语句是赋值、函数调用、还是作用域块。4.2 处理条件块和 CONFIG 开关切分之后写作用域解析器。qmake 的win32 { ... }和win32: SOURCES x.cpp是两种语法形式但语义一样。统一解析成“条件前缀 语句体”的结构。import re _SCOPE_COND re.compile(r^([a-zA-Z0-9_|!()]):\s*(.*)$) _BLOCK_OPEN { _BLOCK_CLOSE } class ScopeBlock: def __init__(self, condition: str): self.condition condition self.body: list[str] [] def parse_scopes(statements: list[str]) - list[ScopeBlock]: stack: list[ScopeBlock] [] root ScopeBlock() stack.append(root) for st in statements: if st _BLOCK_OPEN: continue if st _BLOCK_CLOSE: if len(stack) 1: stack.pop() continue m _SCOPE_COND.match(st) if m and m.group(2) and m.group(2) ! _BLOCK_OPEN: # 单行条件: win32: SOURCES a.cpp cond, body m.groups() block ScopeBlock(cond) block.body.append(body) stack[-1].body.append(block) else: stack[-1].body.append(st) return root.body这里把win32: SOURCES x转成一个ScopeBlockbody 里放的是原语句的剩余部分。对整个.pro文件跑完后可以得到一个作用域树树根是无条件分支叶子是各平台条件块。条件的映射规则要单独维护win32对应if(WIN32)unix对应if(UNIX)macx对应if(APPLE)!android对应if(NOT ANDROID)。CONFIG(debug, debug|release)这种带参数的条件判断要拆成两部分把配置名和候选列表分别提取出来生成 CMake 的if($CONFIG:Debug)或等价的if(CMAKE_BUILD_TYPE STREQUAL Debug)。CONFIG开关的处理和条件块类似。.pro里常见的CONFIG release、CONFIG debug_and_release不能直接搬到 CMake——CMake 的构建类型是由CMAKE_BUILD_TYPE或CMAKE_CONFIGURATION_TYPES决定的qmake 的CONFIG不能直接控制。迁移策略是CONFIG console转换成set_target_properties(... PROPERTIES WIN32_EXECUTABLE FALSE)CONFIG c17转换成CMAKE_CXX_STANDARD其他CONFIG选项如果没有对应的 CMake 功能就只在转换报告里提示不强转。4.3 生成 CMakeLists.txt按 Qt5/Qt6 分别输出 find_package最后是组装输出。生成器函数的输入是解析好的变量字典和作用域树输出是 CMakeLists.txt 的文本。核心逻辑是把SOURCES、HEADERS、RESOURCES、DEFINES、INCLUDEPATH、LIBS、QT分别映射到 CMake 语句。def generate_cmake(vars_: dict, target_name: str, template: str, qt_major: int) - str: lines [fcmake_minimum_required(VERSION 3.16), fproject({target_name}), ] lines.append(fset(CMAKE_CXX_STANDARD {vars_.get(CMAKE_CXX_STANDARD, 17)})) lines.append(set(CMAKE_AUTOMOC ON)) lines.append(set(CMAKE_AUTORCC ON)) lines.append() components .join(vars_.get(QT_COMPONENTS, [Core, Gui, Widgets])) lines.append(ffind_package(Qt{qt_major} REQUIRED COMPONENTS {components})) lines.append() source_list .join(vars_.get(SOURCES, [])) header_list .join(vars_.get(HEADERS, [])) resource_list .join(vars_.get(RESOURCES, [])) lines.append(fadd_executable({target_name} {source_list} {header_list} {resource_list})) lines.append() inc_dirs vars_.get(INCLUDEPATH, []) if inc_dirs: lines.append(ftarget_include_directories({target_name} PRIVATE { .join(inc_dirs)})) defines vars_.get(DEFINES, []) if defines: lines.append(ftarget_compile_definitions({target_name} PRIVATE { .join(defines)})) libs vars_.get(LIBS, []) if libs: lines.append(ftarget_link_libraries({target_name} PRIVATE { .join(libs)})) # Qt 库目标名映射 lines.append() lines.append(ftarget_link_libraries({target_name} PRIVATE) for comp in vars_.get(QT_COMPONENTS, []): lines.append(f Qt{qt_major}::{comp}) lines.append()) return \n.join(lines)参数说明qt_major由第一节的qmake -query结果决定5 还是 6 影响find_package和Qt5::Widgets这种目标名的生成。CMAKE_AUTOMOC与CMAKE_AUTORCC之所以要在所有 Qt 工程里统一开启是因为 qmake 的moc、rcc是构建时自动处理的CMake 对应的自动化开关必须在文件头部设置否则HEADERS里的Q_OBJECT类不会生成 moc 文件。条件块的输出还要单独处理。作用域树里的if(WIN32)分支生成的语句要包裹在 CMake 的if(WIN32)中比如if(WIN32) target_sources(myapp PRIVATE src/win_utils.cpp) endif() if(UNIX AND NOT APPLE) target_sources(myapp PRIVATE src/linux_utils.cpp) endif()这一步的输出我一般不会直接替换原项目而是生成CMakeLists.new.txt和手工对照版放在一起 diff。生成的脚本建议用 Python 的argparse接收.pro路径和 Qt 版本参数方便在多个工程间批量跑。5. q2c 转换后最容易翻车的五个坑现象、原因、对策5.1 现象cmake 配置阶段报 Qt5Config.cmake 找不到转换完成后第一次跑cmake ..最常遇到的报错类似这样CMake Error at C:/Qt/qt5.9.4/5.9.4/msvc2017_64/lib/cmake/Qt5/Qt5Config.cmake:9: Could not find a package configuration file provided by Qt5原因很直接qmake 靠自身可执行文件的位置定位 Qt 安装目录CMake 则完全依赖CMAKE_PREFIX_PATH或find_package的PATHS提示两者定位机制不同。.pro里写的QT widgets被转换成了find_package(Qt5 COMPONENTS Widgets)但如果CMAKE_PREFIX_PATH没指向 Qt 的lib/cmake上层目录CMake 就找不到配置文件。解决方式是在 CMakeLists.txt 顶部加一条可覆盖的变量设置if(NOT DEFINED CMAKE_PREFIX_PATH) set(CMAKE_PREFIX_PATH C:/Qt/qt5.9.4/5.9.4/msvc2017_64) endif()绝对路径写在工程文件里不干净但作为迁移期的临时垫片足够。正式做法是把它放进 CI 的环境变量或者在 CMakeLists 里通过$ENV{QT_ROOT}读取外部传入的 Qt 路径。另外如果错误信息停在了CMakeDetermineCompilerId.cmake这类文件上那通常是编译器探测失败了先检查 C/C 编译器路径不要继续在 q2c 的输出里找原因。5.2 现象Windows 下命令行程序变成黑框或者看不到调试输出.pro里写的CONFIG console转换成 CMake 后如果只生成了add_executable程序在 Windows 下会以 GUI 子系统方式链接双击运行时没有控制台printf/qDebug()输出也看不到。在开发阶段这非常讨厌调试信息全被吞掉。原因是 qmake 的console配置控制的是链接器的/SUBSYSTEM:CONSOLE参数CMake 里等价设置是WIN32_EXECUTABLE目标属性。转换脚本要做的不是生成额外的链接选项而是确保没有错误地把这个属性置真。正确输出是set_target_properties(myapp PROPERTIES WIN32_EXECUTABLE FALSE )如果源码里确实调用了WinMain那就反过来需要显式设为TRUE。判断依据不是看.pro里有没有CONFIG console而是看入口函数是main还是WinMain。迁移期间我建议一律保持控制台子系统等程序稳定后再切换省去由于输出不可见造成的排错麻烦。5.3 现象程序图标、qss、翻译文件全部丢失运行时报资源找不到转换后的程序能编译能启动但图标没了、QSS 样式不加载、QTranslator加载失败。原因基本只有一个RESOURCES app.qrc没有被写进 CMake 的源文件列表或者写进去了但AUTORCC没开.qrc被当成了普通文本文件。qmake 对.qrc的构建是隐式的只要出现在RESOURCES变量里qmake 会调用rcc编译成二进制资源并链接进目标。CMake 里对应的机制是AUTORCC开启后.qrc文件只要出现在目标源文件列表里就会被自动处理。生成器必须保证输出里同时包含这两部分set(CMAKE_AUTORCC ON) add_executable(myapp app.qrc)如果 Qt 版本是 6还可以用qt_add_resources做更细粒度的控制但迁移期先用AUTORCC最小改动跑通。转换脚本里检查RESOURCES变量为空时就输出一条警告提醒开发者确认.pro里是否真的没有资源文件——多数情况是有的只是解析时漏掉了。5.4 现象编译报 moc 文件重复定义或者信号槽链接不上moc的处理是 q2c 转换里一眼看不出的隐患。.pro里HEADERS mainwindow.h只声明了头文件qmake 会自动对包含Q_OBJECT的头文件运行 moc。CMake 侧如果开了AUTOMOC同样会自动处理不会报错。但如果转换脚本自作聪明把moc_mainwindow.cpp写进了SOURCES就会和自动生成的 moc 文件撞车链接时出现重复符号。如果没开AUTOMOC症状则是另一个方向编译能过但运行时connect调用返回 false信号槽不触发Q_OBJECT类里的元对象代码完全缺失。对策是在 CMakeLists.txt 顶部统一设置set(CMAKE_AUTOMOC ON) set(CMAKE_INCLUDE_CURRENT_DIR ON)INCLUDE_CURRENT_DIR很关键AUTOMOC生成的ui_*.h和moc_*.cpp需要能在当前源文件目录找到头文件qmake 默认包含这些目录CMake 需要显式开启。转换脚本遇到HEADERS列表时不要额外生成任何moc_开头的源文件直接交给自动机制处理。5.5 现象链接错误“无法解析的外部符号”库的依赖顺序不对qmake 的LIBS -lfoo -lbar基本是按书写顺序传给链接器的。CMake 的target_link_libraries表面上也按顺序展开但行为有差异CMake 会解析库之间的依赖关系静态库的链接顺序必须保证“被依赖的库排在依赖它的库后面”否则链接器会跳过看似无用的静态库。转换脚本如果直接执行LIBS -lfoo -lbar到target_link_libraries(myapp PRIVATE foo bar)的机械映射foo 依赖 bar 时bar 没出现在 foo 之后链接就会失败。解决方式是转换时做一次依赖排序。简单方案是记录.pro里LIBS的书写顺序倒序输出因为 CMake 的链接顺序要求从左到右解析最底层的库放在最后复杂方案是先判断库类型动态库顺序不敏感静态库才需要严格排序。我一般建议迁移期先手工确认项目里的LIBS顺序再决定要不要写排序逻辑。qmake 的写法里如果用了-L$$PWD/lib指定搜索路径CMake 里要拆成target_link_directories(myapp PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/lib) target_link_libraries(myapp PRIVATE foo bar)target_link_libraries里不要出现-l前缀CMake 会按目标名或全路径自动找到对应库。直接把-lfoo原样塞进去会让 CMake 尝试找名为-lfoo的目标链接时又报一次“找不到文件”。6. 验证 q2c 的输出质量用 cmake --trace 反向核对生成的东西6.1 用 cmake --trace 检查头文件路径和宏定义是否和 qmake 一致转换脚本写完后第一件事不是看能不能编译而是对比 qmake 和 CMake 实际使用的编译参数。CMake 配置阶段可以用 trace 模式把每一条变量读写打出来。cmake --trace --trace-expand .. 21 | grep target_include_directories--trace输出 CMakeLists.txt 中各语句的执行过程和变量值。重点查INCLUDEPATH对应的include_directories列表和DEFINES对应的宏定义看有没有漏项。VSCode 里装了 CMake Tools 的话底部状态栏点 Configure 按钮就能直接触发配置输出面板里会集中显示这类 trace 信息比命令行翻日志直观。另一种验证方式是对比编译命令。qmake 生成的 Makefile 里能直接找到编译器命令行CMake 的compile_commands.json也记录了每个源文件的完整编译命令。两者放在一起 diff差异项就是转换漏掉的东西。6.2 保留 qmake 构建输出作对照组做文件级 diff迁移期间不要删掉.pro保留一份能正常构建的 qmake 工程作对照组。做法是分别用 qmake 和 CMake 各构建一次收集目标产物里的文件清单。Windows 下用dumpbin /symbolsLinux 下用nm比对静态库和可执行文件导出的符号确认 Q_OBJECT 元对象、qrc 资源、翻译文件都完整进入产物。如果差异集中在个别模块基本就是解析器对某个 qmake 函数支持不全直接对照.pro原文修正映射规则即可。这个阶段我不要一次性迁移全部工程选一个中等规模、边界情况多的子模块当试验田跑通验证流程后再铺开到其余工程。6.3 一个值得长期保留的小习惯经历几次迁移后我现在的做法是新仓库一律直接写 CMakeLists.txt不再引入 qmake旧仓库先跑一遍 q2c 生成草稿然后手工收敛所有平台分支和自定义函数收敛完的 CMake 工程替换原构建.pro文件留档三个月再删。这样既保住了迁移节奏又不用维护两套构建系统。验证脚本我习惯直接留在工程的tools/目录里每次 CMake 变更都可以重新比对一次防止重构时悄悄引入编译参数层面的差异。希望这个验证思路能帮你在迁构建系统时少走点弯路。本文还有配套的精品资源点击获取