Qt 编译方式之 qbs

作者：billy
版权声明：著作权归作者所有，商业转载请联系作者获得授权，非商业转载请注明出处

QBS简介

QBS（Qt Build Suite）同 qmake、cmake 之类一样都是构建工具。QBS 号称是下一代的构建工具(博主的理解上一代是基于 makefile 的构建工具)。根据官网介绍，Qbs 极有可能会替代 qmake 成为 Qt 6.0 的构建系统，与 qmake 相比，Qbs 提供了更快构建速度，以及更多的特性。

和qmake不一样，qbs没有绑定Qt版本，它从项目文件的高级项目描述中生成一个正确的编译表（依赖表）。而传统的MakeFile生成工具比如qmake和CMake生成了makefile文件，然后将实际的命令留给make或者ninja这样的工具去执行。Qbs的另一方面就是充当了并行生成与直接调用编译器、连接器以及其他工具的角色，非常像SCons和Ant做的事情。

Declarative语言

qbs的语法是一个简化版本的qml，提供了对IDE友好的软件项目的展示。它同样提供了自由使用任何JavaScript表达式进行属性绑定的支持。
万事从 “Hello world” 开始，我们创建一个最基础的程序来看下 qbs 如何构建项目：

consoleApplication: true 代表了这是一个控制台程序。
files: “main.cpp” 则列出了源文件(不仅仅只是 C++头文件和源文件)
多个文件时：files: [“foo.h”, “foo.cpp”, “main.cpp”]
fileTagsFilter: “application” 代表的意思就是 CppApplication 的 type 属性为 “application”， CppApplication 是一个可执行程序，常用的类型还有 dynamiclibrary(动态库)、staticlibrary 静态库。

Group 将一组在某些行为上是一样的文件组合成一组，比如某些将安装到同一目录下的文件。
Group 分组的对象是文件，如果 Group 项内没有指定有效文件，那么这个 Group 是会被忽略的。
Group 项指定文件可以用 files 属性或 fileTagsFilter 属性，这两个属性是互斥的只能用其一。
files: 指定文件列表。
fileTagsFilter: 指定文件标记名，通过标记名来匹配文件。

qbs Property Documentation

1. architecture : string
   目标平台的处理器体系结构。
   未定义表示目标平台独立于体系结构（例如clr或jvm），此属性通常在配置文件中设置。
   常用值为：“x86”、“x86_64”和“arm”，默认：未定义。

2. architectures : stringList
   产品将为其构建的体系结构。
   默认值：Android上是[armv5te]，与苹果平台上的xcode相同，否则等同于[qbs.architecture]。

3. buildVariant : string
   构建模式的名称。
   可能的值是“debug”和“release”。如果 qbs.configurationname 为“release”，则默认为“release”，否则为“debug”。

4. buildVariants : stringList
   构建模式的名称列表。
   默认值：相当于[qbs.buildvariant]。

5. debugInformation : bool
   是否生成调试信息。
   默认值：对于调试版本为true，否则为false。

6. enableDebugCode : bool
   是否在产品中启用调试功能。不要与生成调试符号或代码优化级别混淆。
   通常，此属性对 debug 启用，对 release 禁用。
   默认值：对于调试版本为true，否则为false。

7. hostOS : stringList
   此属性由QBS内部设置，并指定OS QBS正在运行。
   此属性的可能值是TargetOS的值，即使其中某些值可能不受支持，默认：未定义。

8. hostPlatform : string
   主机平台，注：不要使用此属性。
   默认：自动确定。

9. install : bool
   是否安装某组文件。
   此属性通常设置在组项中，以将多个文件标记为可安装。
   注意：启用此属性的项目将自动接收文件标记“installable”。这对于编写与包装相关的规则很有用，默认值：false

10. installDir : string
    产品或组文件的安装目录。
    此属性的值是相对于InstallPrefix的路径，默认：未定义

11. installPrefix : string
    全局安装前缀。它隐式地预加在installdir的所有值之前。
    此属性本身的值在安装上下文中相对于InstallRoot，默认：[]

12. installRoot : string
    全局安装根目录。
    在安装上下文中，它隐式地预加了installPrefix的所有值。
    注意：此属性与InstallDir和InstallPrefix有根本不同，因为它对正在构建的代码不可见。实际上，install根目录通常只是用于打包二进制文件的临时位置，因此不应假定它们在运行时位于该位置。出于同样的原因，通常不从项目文件中设置此属性。默认值：/install-root

13. installSourceBase : string
    要安装的本地文件的基目录。
    从installdir中指定的目标目录路径中省略源基目录。
    默认：要安装的当前文件的目录，相对于产品的源目录。

14. nullDevice : string
    与空设备对应的平台特定文件路径。
    默认值：在Windows上为“nul”，在Unix上为/dev/null。

15. optimization : string
    所有工具链都应执行的一般优化类型。
    允许值为：
    “fast”
    “none”
    “small”
    默认值：调试版本为“none”，发布版本为“fast”。

16. pathListSeparator : string
    环境变量或其他上下文中使用的路径列表的平台特定分隔符。
    在Windows上默认为“；”，在Unix上默认为“：”。

17. profiles : stringList
    构建产品的配置文件。
    对于这里列出的每个概要文件，将根据各自概要文件中设置的属性构建一个产品实例。
    默认值：[project.profile]

18. shellPath : path
    与命令行解释器对应的平台特定文件路径。
    在Windows上，这是保存在comspec环境变量（通常是c:/windows/system32/cmd.exe）中的cmd.exe的路径，在类Unix平台上，这是/bin/sh。
    默认值：Windows上"%COMSPEC%"，Unix上“bin/sh”

19. sysroot : string
    目标平台的sysroot。
    此属性通常设置在用于交叉编译的配置文件中。默认：未定义

20. targetOS : stringList
    指定要为其生成项目的操作系统。
    使用此属性在条件中测试特定OS或OS系列。请勿为此目的使用TargetPlatform。
    可能的值包括“bsd”、“darwin”和“unix”中的一个或多个，以及targetform的可能值。
    默认：未定义

21. targetPlatform : stringList
    要为其生成项目的操作系统。
    此属性通常设置在配置文件中或特定产品中，目标操作系统始终是已知的（例如以本机代码编写的Apple Watch应用程序）。通常应将此属性视为只写，并避免使用它来测试当前目标操作系统。
    可能的值包括以下一个或多个：

"aix"
"android"
"freebsd"
"haiku"
"hpux"
"hurd"
"integrity"
"ios"
"ios-simulator"
"linux"
"lynx"
"macos"
"netbsd"
"openbsd"
"qnx"
"solaris"
"tvos"
"tvos-simulator"
"vxworks"
"watchos"
"watchos-simulator"
"windows"

默认：未定义

22. toolchain : stringList
    工具链的属性用于构建。
    典型值包括“llvm”，以及toolchaintype的可能值。默认：未定义

23. toolchainType : string
    工具链用于构建。
    通常应将此属性视为只写，并避免使用它来测试当前的工具链。
    典型值包括：“gcc”、“clang”、“mingw”、“msvc”和“xcode”。
    默认：自动确定。

24. [read-only] configurationName : string
    当前生成配置的名称。
    构建配置是通过命令行参数config设置的。默认：“default”

25. [read-only] hostOSBuildVersion : string
    主机操作系统的内部版本。
    目前，仅为Windows和Apple平台定义，默认：未定义
    在Windows上，这是4位或5位Windows内部版本号，相当于versionPatch。
    在苹果平台上，这是苹果版本控制方案中的标准版本号。例如，“13C64”。

26. [read-only] hostOSVersion : string
    主机操作系统版本。
    目前，仅为Windows和Apple平台定义， 默认：未定义
    由两个或三个由点分隔的数字组成。例如，“10.9”或“6.3.9600”。

27. [read-only] hostOSVersionParts : list
    主机操作系统版本列表。
    例如，Windows8.1（版本6.3.9600）对应的值为[6，3，9600]，默认：[]

28. [read-only] hostOSVersionMajor : int
    主机操作系统主版本。
    默认值：hostoVersionParts[0]

29. [read-only] hostOSVersionMinor : int
    主机操作系统次版本。
    默认值：hostosVersionParts[1]

30. [read-only] hostOSVersionPatch : int
    主机操作系统修补程序级别。
    默认值：hostosVersionParts[2]

31. [read-only] version : string
    QBS版本号。例如，“1.4.1”。

32. [read-only] versionMajor : int
    QBS的主要版本号。

33. [read-only] versionMinor : int
    QBS的次要版本号。

34. [read-only] versionPatch : int
    QBS的补丁版本号。

Group QML Type

1. condition : bool
   确定组中的文件是否实际视为项目的一部分。默认值：true

2. excludeFiles : list
   从文件列表中减去的文件列表。使用通配符时很有用。默认：一个空的列表

3. fileTags : list
   要附加到组文件的文件标记列表。然后可以用一个规则来匹配它们。
   注意：文件标记器从不应用于设置了此属性的文件。默认：一个空的列表

4. fileTagsFilter : list
   要匹配的artifact.filetags列表。
   此组中设置的任何属性都将应用于产品的工件，其文件标记与此处列出的标记匹配。
   组的file tags属性指定的文件标记将添加到匹配的项目中。此属性与文件互斥。
   默认：一个空的列表

5. files : list
   组中的文件。与FileTagsFilter互斥。
   使用包含组项的文件的父目录解析相对路径。但是，如果prefix属性设置为绝对路径，则该路径将成为基目录。默认：一个空的列表

6. filesAreTargets : bool
   如果此属性为true且组位于模块中，则组中的文件将不会成为依赖于模块的产品的源工件。相反，它们被视为产品的目标工件。也就是说，它们将与依赖模块的产品中的规则的inputsFromDependencies文件标记列表相匹配。默认值：false

7. name : string
   组的名称。不在内部使用；主要用于IDE。
   默认值：“Group x”，其中x是产品中所有组中的唯一数字。

8. overrideTags : bool
   确定如何处理同时在产品（或父组，如果有）和组的顶级列出的文件上的标记。
   如果此属性为真，则通过组设置的文件标记将替换通过产品或父组设置的标记。如果为假，则将组标记添加到父标记中。如果设置了FileTagsFilter，则忽略此属性。默认值：true

9. prefix : string
   用于预处理所有文件的字符串。允许斜杠并具有目录语义。
   默认值：父组的前缀（如果存在），否则为空。

案例

通常我们使用Group 指定安装文件的目标目录。
要安装一组文件，请将该组的 qbs.install 属性设置为true，qbs.installdir 的值指定文件安装目录的路径。可以将所有安装目录的基目录指定为 qbs.installPrefix 的值。
例如，以下属性指定在Windows和Linux上安装一组QML文件和应用程序可执行文件的位置：

 Application {
      name: "myapp"
      Group {
          name: "Runtime resources"
          files: "*.qml"
          qbs.install: true
          qbs.installDir: condition: qbs.targetOS.contains("unix")
              ? "share/myapp" : "resources"
      }
      Group {
          name: "The App itself"
          fileTagsFilter: "application"
          qbs.install: true
          qbs.installDir: "bin"
      }
      qbs.installPrefix: condition: qbs.targetOS.contains("unix")
          ? "usr/local" : "MyApp"
  }

在Windows上，qml文件最终将安装在myapp\resources中，应用程序可在myapp\bin中执行。
在Linux上，qml文件将安装在/usr/local/share/myapp中，可执行文件将安装在/usr/local/bin中。

前景

这是一个试验性质的项目，用来试验不同编译工具概念。qmake仍然会存在很长一段时间，并且没人会强迫谁去使用qbs，或者其它任何编译工具。尽管在某些时候我们肯定会尝试将qbs作为Qt自身的编译系统来使用。

通用元编译工具，比如CMake或者GNU Autotools的用户也许注意到了，严谨来说，qbs与跨平台编译工具相比有一个关键部分的缺失：适应宿主环境，就是所谓的配置检查。当前，qbs仍然需要一个外部的配置脚本来生成一个JSON格式的文件，从而能被qbs调用。但是这终究不是一个长久的解决方法。关键点在于使配置测试像其他模块一样可用。其实现当然不止包括了Declarative，还包含了一些JavaScript代码。