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"

默认:未定义

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

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

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

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

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

  6. [read-only] hostOSVersionParts : list
    主机操作系统版本列表
    例如,Windows8.1(版本6.3.9600)对应的值为[6,3,9600],默认:[]

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

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

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

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

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

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

  13. [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代码。

发布了61 篇原创文章 · 获赞 218 · 访问量 1万+

猜你喜欢

转载自blog.csdn.net/qq_34139994/article/details/98478648
今日推荐