[官方文档][中文翻译by ChatGpt] 如何移植Cobalt #YouTube

报告队长
168 阅读4分钟

本文档提供了逐步说明，以便将Cobalt移植到您的平台上运行。为此，您将使用Starboard，它是Cobalt的移植层和操作系统抽象层。Starboard仅封装Cobalt使用的特定于平台的功能。

要完成移植，您需要向Cobalt源代码树中添加代码。我们意识到，许多移植者可能不希望实际上与外部用户共享其Starboard实现的详细信息。这些移植者可能有自己的源代码控制，并将Cobalt分叉到其软件配置管理（SCM）工具中。这些说明考虑了这种用例，并解释了如何以不与未来的Cobalt源代码更改冲突的方式添加您的移植。

先决条件

要完成下面的说明，首先需要克隆Cobalt源代码库：

$ git clone <https://cobalt.googlesource.com/cobalt>

如果您愿意，您也可以完成在Linux上设置Cobalt开发环境的说明。检出Cobalt源代码是该过程中的一步。

移植步骤

1. 枚举和为您的平台配置命名

您的第一步是为您的平台配置定义规范名称。稍后，您将使用这些名称来组织您平台的代码。

平台配置与生产二进制的一对一映射。因此，每当您需要生成新的二进制文件时，您都需要创建一个新的平台配置。

平台配置名称由两个组成部分组成：

  • <family-name>是一个名称，涵盖您要移植到Starboard的一组产品。
  • <binary-variant>是一个字符串，唯一描述该配置生成的二进制文件的特定信息。

平台配置的推荐命名约定是：

    -

例如，假设一个名为BobCo的公司生产各种BobBox设备。其中一些设备使用大端ARM芯片，而其他设备使用小端ARM芯片。BobCo可能定义了两个平台配置：

  • bobbox-armeb
  • bobbox-armel

在此示例中，bobbox是家族名称，并在BobCo的所有平台配置中使用。具有大端ARM芯片的设备的binary-variant是armeb。对于使用小端ARM芯片的设备，binary-variant是armel。

2. 为您的Starboard移植添加源代码树目录

为您在第1步中选择的<family-name>向源代码树添加以下目录：

  • third_party/starboard/<family-name>/

  • third_party/starboard/<family-name>/shared/

    此子目录包含在产品系列内的不同体系结构之间共享的代码。例如，如果BobBox设备在许多不同平台上运行，则BobCo需要为每个平台定义不同的配置。但是，如果所有配置都可以使用相同的Starboard函数实现，BobCo可以将该函数放在shared目录中，以便在每个二进制变体中都可以访问。

  • third_party/starboard/<family-name>/<binary-variant>/

    您应该为每个<binary-variant>创建一个目录。因此，例如，BobCo可以创建以下目录：

    * third_party/starboard/bobbox/shared/
* third_party/starboard/bobbox/armeb/
* third_party/starboard/bobbox/armel/
* third_party/starboard/bobbox/armel/gles/

再次，适用于所有配置的函数将放在shared目录中。适用于所有小端设备的函数将放在armel目录中

和适用于使用OpenGL ES的小端设备的函数将放在armel/gles目录中。

3. 添加所需的binary-variant文件

您在第2步中创建的每个binary-variant目录都必须包含以下文件：

  • atomic_public.h
  • [BUILD.gn](http://build.gn/)
  • configuration_public.h
  • platform_configuration/[BUILD.gn](http://build.gn/)
  • platform_configuration/configuration.gni
  • toolchain/[BUILD.gn](http://build.gn/)

我们建议您从Stub参考实现中复制这些文件，该文件位于starboard/stub/，并将其复制到您的binary-variant目录中。使用这种方法，您将从干净的Stub接口开始，需要修改它们以适应您的平台。

另一种方法是复制桌面Linux或Raspberry Pi端口，然后逐步修复在您的平台上无法编译或工作的问题。

如果您正在复制Stub实现，您将为每个binary-variant目录运行以下命令：

cp -R starboard/stub third_party/starboard/<family-name>/<binary-variant>

复制这些文件后，您应该能够编译Cobalt并将其与您的工具链链接起来，即使代码本身尚不起作用。

3a. Stub实现中的其他文件

Stub实现包含三个额外的文件，这些文件不在每个binary-variant目录的所需文件列表中：

  • [application_stub.cc](http://application_stub.cc/)
  • application_stub.h
  • [main.cc](http://main.cc/)

Starboard的Application类旨在执行以下操作：

  • 将通用的消息循环函数与可以传递输入或应用程序生命周期事件（如暂停/恢复）的系统消息泵集成。
  • 提供一个优雅的平台特定初始化和拆卸的地方。
  • 提供一个可普遍访问的地方来存储全局平台特定状态，例如受管理的UI窗口。

因此，这些文件提供了一个框架，用于满足Starboard的事件分派要求，即使它们不实现任何特定的Starboard接口，也不是任何给定端口的严格必需品。即使如此，任何移植Cobalt的人都可能需要根据其平台的需求调整[application_stub.cc](http://application_stub.cc/)和application_stub.h的副本。

application文件不一定需要是每个变体文件。即使您有多个变体，您仍然可能只需要在您的shared目录中拥有一个副本。同样，您可能会有一个共享的基类以及特定于变体的子类。

4. 进行所需的文件修改

要移植代码，您必须将您的平台添加到starboard/build/platforms.py，然后对第3步中复制的文件进行以下修改：

  1. atomic_public.h - 确保此文件指向适当的共享或自定义实现。

  2. configuration_public.h - 根据您的平台适当调整所有[配置值](
    ../../reference/starboard/configuration-public.html)。

  3. platform_configuration/[BUILD.gn](http://build.gn/)
    - 更新您的平台命令行标志和库。确保不要假设特定的工作站布局，因为该布局可能因用户而异。

  4. platform_configuration/configuration.gni
    - 如果需要，从starboard/build/config/base_configuration.gni文件中更新文件中的以下变量的值：
    * gl_type - 如果您使用系统EGL + GLES2实现，则设置为system_gles2，否则将该值设置为none。
    * enable_in_app_dial - 启用（或禁用）在Cobalt内部运行的DIAL服务器。 （此服务器仅在Cobalt运行时运行。）DIAL协议使第二屏设备（如平板电

视和手机）能够发现、启动和与第一屏设备（如电视、机顶盒和蓝光播放器）上的应用程序进行交互。

   - 如果您已经拥有系统范围的DIAL支持，则将此值设置为false。在这种情况下，Cobalt内部运行的DIAL服务器将是多余的。
- 如果您希望Cobalt在运行时始终运行DIAL服务器，则将此值设置为true。该服务器仅可用于与当前Cobalt应用程序（例如YouTube）建立连接。

  1. toolchain/[BUILD.gn](http://build.gn/)
    - 如果您的平台使用简单的clang工具链，只需将工具链的路径传递给clang_toolchain模板。该模板将假设每个工具的名称，即clang++可执行文件应位于${clang_base_path}/clang++。

     修改主机的toolchain_args，以传递正确的操作系统和CPU给您的主机平台。

     如果您的工具链使用GCC或具有与clang_toolchain模板假设的工具名称不同的工具名称，请使用gcc_toolchain模板（也提供在"//build/toolchain/gcc_toolchain.gni"中）。要使用此模板，请传递每个所需工具（ar、cc、cxx和ld）的完整路径，以及您想要使用的任何可选工具。如果您的工具链使用clang，请确保在toolchain_args中传递is_clang = true。

   - 更新您的工具链命令行标志和库。确保不要假设特定的工作站布局，因为该布局可能因用户而异。

5. 移植模块以在您的平台上工作

[BUILD.gn](http://build.gn/)文件指向包含在您的新Starboard实现中的所有源文件。如果您从Stub实现的副本开始，那么该文件最初将包含来自starboard/shared/stub/目录的许多文件。同样，如果您从桌面Linux端口的副本开始，那么该文件最初将指向starboard/shared/posix目录中的文件。

这些模块被定义为每个模块具有一组函数，并且每个函数在其自己的文件中定义，具有一致的命名约定。例如，SbSystemBreakIntoDebugger()函数在[system_break_into_debugger.cc](http://system_break_into_debugger.cc/)文件中定义。starboard/shared/stub/目录中的文件列表表示受支持函数的权威列表。

逐个函数和逐个模块，您现在可以将存根实现替换为自定义实现或来自starboard/shared/目录的其他移植实现，直到完成所有模块。在这样做时，更新[BUILD.gn](http://build.gn/)文件以标识适当的源文件。

由于模块之间的依赖关系，您会发现在其他模块之前使一些模块通过NPLB测试更容易。我们建议按照以下顺序进行移植模块，以考虑此类依赖关系：

  1. 配置
  2. main()、Application和Event Pump - 这是对SbEventHandle的调用。
  3. 内存
  4. 字节交换
  5. 时间
  6. 字符串/字符/双精度
  7. 日志
  8. 文件
  9. 目录
  10. 系统
  11. 原子
  12. 线程和线程类型
  13. 互斥锁
  14. 条件变量
  15. 一次性
  16. 套接字
  17. SocketWaiter
  18. 窗口
  19. 输入
  20. Blitter（如果适用）
  21. 音频接收器
  22. 媒体和播放器
  23. DRM
  24. 时区
  25. 用户
  26. 存储

6. 构建和测试

完成上述步骤后，您可以构建Cobalt并使用您的平台工具链链接它。根据您的平台和工具链的不同，可能需要进行一些额外的配置和调整。确保按照您的平台的要求进行正确的构建和链接。

完成构建后，您可以使用Starboard的测试套件来测试您的移植。Starboard提供了一组标准的NPLB（Native Performance Lab Browser）测试，用于评估Cobalt的性能和功能。运行这些测试可以验证您的移植是否正确工作。

要运行NPLB测试，请按照以下步骤操作：

  1. 在Cobalt源代码目录中，运行以下命令：

   sh    $ gn gen out/your_platform --args='is_debug=false'    

   将your_platform替换为您的平台名称。

  1. 进入out/your_platform目录，运行以下命令：

   sh    $ ninja -C . cobalt_nplb    

   这将构建Cobalt NPLB测试套件。

  1. 运行NPLB测试套件：

   sh    $ ./cobalt_nplb    

   运行测试可能需要一些时间，请耐心等待测试完成。

在完成移植和测试后，您应该可以在您的平台上运行Cobalt，并且它应该与Cobalt的功能和性能一致。

请注意，这些步骤提供了一个基本的框架来移植Cobalt到您的平台。根据您的平台和需求的不同，可能需要进行一些额外的调整和修改。确保仔细阅读Cobalt和Starboard的文档，并参考示例移植和其他资源，以获得更详细和特定于您的平台的指导。

avatar
文章
阅读
粉丝