exOS使用助手 > exOS Automation Help > Development > exOS build-chain in Automation Studio

构建 Linux 源代码需要一个构建环境。本帮助侧重于使用 WSL。当然也可以使用其他编译系统，尽管只提到了 WSL，但 exOS 技术软件包并不直接依赖于 WSL。

当设置了适当的环境后，exOS 构建插件会检查exoscomponent 文件中引用的所有软件包，并在每个 exospkg 文件的 <Build> 部分中搜索 <BuildCommand> 指令。同样，如果需要更多的编译步骤（而且编译脚本还没有解决这个问题），可以在exospkg 文件中添加多个 <BuildCommand>指令。

<BuildCommand> 定义了以下属性：

▪命令：

可执行 "编译器 "的完整系统路径。请注意示例中的Sysnative 条目，它取代了 System32文件夹，否则会重定向到 SYSWOW64，因为 exOS build-plugin 是作为 32 位进程运行的，而 WSL 是 64 位进程（尽管 WSL 在文件资源管理器中位于 C:\Windows\System32 下）。有关 Sysnative 设置的更多信息，请参阅 https://superuser.com/a/1528297。在示例中，WSL 用于触发 Linux 子系统中的构建脚本。当然，也可以执行任何其他命令或工具。

▪WorkingDirectory（工作目录）：

运行命令的工作目录，相对于 exospkg 文件。在示例中，WSL 在 WaterTank 软件包的 Linux 文件夹中运行。

▪参数：

传递给命令的参数。在上例中， DebianWSL 发行版启动，并执行sh build.sh $(EXOS_VERSION)。

•$(EXOS_VERSION)

$(EXOS_VERSION) 可以放在Arguments 属性的任意位置，并将被替换为当前的 exOS TP 版本（目前为2.1.0）。在这种情况下，它将作为参数传递给 build.sh，后者将评估 WSL 构建环境中exos-data-eth 软件包的当前版本是否是最新的。

这意味着以下命令

在 WaterTank\Linux 文件夹中运行 WSL 并执行 build.sh 脚本。此过程的所有输出都会打印在 AS 输出中，并以 [exOS Build] 作为前缀，例如

Executing build command for WaterTank：C:\Windows\Sysnative\wsl.exe -d Debian -e sh build.sh 2.1.0
> -- C 编译器标识为 GNU 8.3.0
> -- CXX 编译器标识为 GNU 8.3.0
> -- 检查 C 编译器是否正常工作：/usr/bin/cc
> -- 检查是否有可用的 C 编译器：/usr/bin/cc -- 工作
> -- 检测 C 编译器 ABI 信息
> 检测 C 编译器 ABI 信息 - 已完成
> -- 检测 C 编译特征
> 检测 C 编译特征 - 已完成
> -- 检查是否有可用的 CXX 编译器：/usr/bin/c++
> -- 检查是否有可用的 CXX 编译器：/usr/bin/c++ -- 工作
> -- 检测 CXX 编译器 ABI 信息
> -- 检测 CXX 编译器 ABI 信息 - 完成
> -- 检测 CXX 编译特性
> 检测 CXX 编译特性 - 已完成
> -- 配置完成
> -- 生成完成
> -- 编译文件已写入/mnt/c/_dev/exOS/exOS-Project/AS/exos_demo/Logical/WaterTank/Linux/build
> 扫描目标水箱的依赖关系
> [ 25%] 构建 C 对象 CMakeFiles/watertank.dir/termination.c.o
> [ 50%] 构建 C 对象 CMakeFiles/watertank.dir/watertank.c.o
> [ 75%] 构建 C 对象 CMakeFiles/watertank.dir/exos_watertank.c.o
> [100%] 链接 C 可执行文件 watertank
> [100%] 已构建目标 Watertank
成功执行 WaterTank 的编译命令

这里应提及 WSL 中使用的构建文件夹。WaterTank 软件包使用了 CMakeLists.txt 文件（ cmake 编译系统），它为编译过程创建了大量文件和文件夹。因此， build.sh 脚本为 WaterTank\Linux文件夹中的所有临时文件创建了一个构建文件夹。现在，由于该构建脚本是作为任意命令调用的，exOS 构建插件无法将构建脚本所做的任何事情重定向到临时文件夹，而临时文件夹会在 "清理配置 "或 "重建 "时被删除。因此，每次联编时都会有意删除联编文件夹，而更改 <Dependency> 文件会在每次更改时触发 Linux 源代码的重建，即使只更改了一个文件。这样做的缺点是会增加几秒钟的编译时间，但能确保生成的 Linux 源码包始终是最新的。如果需要使用较大的 Linux 源代码包，可在 exOS 包中添加预编译的 .deb 包（参见 exospkg的说明）。如果需要详细检查编译过程（查看编译输出文件），则需要在 wsl shell 或其他工程工具（如 VsCode ）中完成，后者也有 CMake 插件。更多详情，请参阅 WSL 调试部分。

BuildCommand 包含以下指令：

▪<依赖关系

这些依赖关系用于了解何时触发 Linux 源代码的新构建。exOS 构建插件会使用与 <GenerateHeader> 指令相同的临时存储空间来检查文件是否被修改。现在，如果编译失败，临时文件夹中的文件显然应该更新。因此，重要的是， "编译命令 "只能在成功时返回 0，而在失败时返回另一个整数。这样，exOS 的编译插件就能获得正确触发编译过程所需的信息。

o文件名（FileName）：相对于 exospkg而言，应监控更改的文件名

Building Linux sources requires a build environment. This help focuses on using WSL. Other build systems can definitely be used, and even though only WSL is mentioned, the exOS Technology Package has no direct dependency towards WSL.

When an appropriate environment has been set up, the exOS build-plugin goes through all packages that are referenced in the exoscomponent file, and searches for the <BuildCommand> instruction in the <Build> section of each exospkg file. Again, if more build steps are required (and this is not already solved in a build script), several <BuildCommand> instructions can be added to the exospkg file.

The <BuildCommand>defines the following attributes:

•Command:

The full system path to the executable "compiler". Please note the Sysnative entry in the example which replaces the System32 folder that would otherwise be redirecting to SYSWOW64 as the exOS build-plugin runs as a 32-bit process and WSL is a 64bit process (even though WSL is found under C:\Windows\System32 in the file explorer). For more about the Sysnative setting, see https://superuser.com/a/1528297. In the example, WSL is used to trigger a build script in the Linux subsystem. Any other command or tool can of course be executed.

•WorkingDirectory:

The working directory for running the Command, relative to the exospkg file. In the example, WSL runs in the Linux folder of the WaterTank package.

•Arguments:

Arguments passed to the Command. This is usually needed, as the command itself would just execute an arbitrary tool. in the example above, the Debian WSL distribution is started and the sh build.sh $(EXOS_VERSION) is executed.

o$(EXOS_VERSION)

The $(EXOS_VERSION) can be put into the Arguments property at any place and will be replaced with the current version of the exOS TP, currently 2.1.0. In this case, it is passed as a parameter to the build.sh which evaluates if the current version of the exos-data-eth package in the WSL build environment is up to date.

This means, the following command

runs WSL in the WaterTank\Linux folder and executes the build.sh script. All output from this process is printed in the Automation Studio Output prepended with [exOS Build], for example:

Executing build command for WaterTank: C:\Windows\Sysnative\wsl.exe -d Debian -e sh build.sh 2.1.0
>   -- The C compiler identification is GNU 8.3.0
>   -- The CXX compiler identification is GNU 8.3.0
>   -- Check for working C compiler: /usr/bin/cc
>   -- Check for working C compiler: /usr/bin/cc -- works
>   -- Detecting C compiler ABI info
>   -- Detecting C compiler ABI info - done
>   -- Detecting C compile features
>   -- Detecting C compile features - done
>   -- Check for working CXX compiler: /usr/bin/c++
>   -- Check for working CXX compiler: /usr/bin/c++ -- works
>   -- Detecting CXX compiler ABI info
>   -- Detecting CXX compiler ABI info - done
>   -- Detecting CXX compile features
>   -- Detecting CXX compile features - done
>   -- Configuring done
>   -- Generating done
>   -- Build files have been written to: /mnt/c/_dev/exOS/exOS-Project/AS/exos_demo/Logical/WaterTank/Linux/build
>   Scanning dependencies of target watertank
>   [ 25%] Building C object CMakeFiles/watertank.dir/termination.c.o
>   [ 50%] Building C object CMakeFiles/watertank.dir/watertank.c.o
>   [ 75%] Building C object CMakeFiles/watertank.dir/exos_watertank.c.o
>   [100%] Linking C executable watertank
>   [100%] Built target watertank
Build command for WaterTank executed successfully

Here the build folder used in WSL should be mentioned. The WaterTank package is using a CMakeLists.txt file (the cmake build system) which creates a lot of files and folders for the build process. The build.sh script therefore creates a build folder for all temporary files within the WaterTank\Linux folder. Now, as this build script is called as an arbitrary command, the exOS build-plugin has no sensible way to redirect anything that the build script does towards a temporary folder that would be removed at "Clean Configuration" or Rebuild. Therefore, the build folder is intentionally deleted at every build, and changing the <Dependency> files will trigger a rebuild of the Linux sources at every change, even though only a single file has been changed. This has the drawback of some extra seconds compile time, but ensures that the generated Linux package is always up-to-date. If larger Linux source packages are to be used, add precompiled .deb packages to the exOS package instead (see the exospkg description for that.) If the build process needs to be examined in detail (going through the build output files), this needs to be done in the wsl shell or in another engineering tool like VsCode that also has a CMake plugin. For more on that, see the WSL Debugging section.

The BuildCommand contains the following instructions:

•<Dependency>

These dependencies are used to know when to trigger a new build of the Linux sources. The exOS build-plugin uses the same temporary storage as the <GenerateHeader> instruction to check if changes have been made to the files. Now, if a build fails, the files in the temporary folder should obviously be updated. Therefore, it is important that the Build Command only returns 0 in case of success, and another integer in case of failure. This gives the exOS build-plugin the necessary information to trigger the build process correctly.

oFileName: Name of the file that should be monitored for changes, relative to the exospkg

Build Linux sources with BuildCommand

Build Linux sources with BuildCommand