CMake + Qt 翻译系统的正确工作流程

Posted 2023-02-19

【中文标题】CMake + Qt 翻译系统的正确工作流程

【英文标题】：A proper workflow for CMake + Qt translation system

【发布时间】：2016-10-23 23:23:03

【问题描述】：

我最近将我的 Qt 项目从 qmake 移到了 CMake 构建系统，现在我正在尝试建立一个翻译系统。我尝试使用qt5_create_translation 宏（记录在here）来更新我的*.ts 文件并生成*.qm 文件。默认情况下，宏在源目录中创建（或更新）*.ts 文件，在构建目录中创建*.qm 文件，这非常合乎逻辑且使用方便。底层lupdate 实用程序的性质是不能破坏 *.ts 文件——它们只能被更新。所以我看到我的工作流程如下：

添加或修改源文件或 UI 文件。 重建项目：新的可翻译字符串将添加到 *.ts 文件中。 现在将实际翻译添加到 *.ts 或“按原样”提交更改，以便以后添加翻译。 将翻译添加到 *.ts 后，立即重建项目以获得最新的 *.qm 文件。

使用此工作流程，*.ts 文件几乎总是与源文件同步，并且每次构建项目时都会生成 *.qm 文件。但是 CMake 的意识形态和/或 CMake 的 Qt5 插件遵循另一种方式。 CMake 正确地将 *.ts 文件视为构建工件，因此它会生成一条规则以在 make clean 上删除它们（从源代码树（！））。这种行为至少被twice 注册为错误，但维护人员似乎坚持认为这不是错误，而是一项功能。

我找到了一个advice 来添加一个带有翻译的子目录和CLEAN_NO_CUSTOM，但是这些修改破坏了构建：将 *.qm 文件添加到可执行目标不会将子目录添加到可执行依赖项列表。所以 build build 找不到 *.qm 文件并停止。

添加自定义 CMake 目标和\或调用lupdate 的命令会削弱Qt5LinguistTools 模块和qt5_create_translation 宏的所有优点。

添加像 here 这样的 CMake 选项看起来像一个丑陋的解决方法，并且不会阻止开发人员在打开 UPDATE_TRANSLATIONS 时因意外调用 make clean 而丢失未提交的翻译。

那么在当前行为中使用 qt5_create_translation 宏的正确方法是什么？

【参考方案1】：

没有do ADD_SUBDIRECTORY，

我只是添加SET_DIRECTORY_PROPERTIES(PROPERTIES CLEAN_NO_CUSTOM TRUE)

打电话之前

QT5_CREATE_TRANSLATION

【讨论】：

@ymoreau 该属性仅对Makefile generators有效